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Abstract 


Today,  we  rely  on  access  to  digital  data  that  are  accessible,  dependable,  and  protected  from 
misuse.  Unfortunately,  this  need  for  accessible  data  also  exposes  organizations  to  a  variety  of 
new  threats  that  can  affect  their  information.  The  Operationally  Critical  Threat,  Asset,  and 
Vulnerability  Evaluation^^  (OCTAVE^^^)  enables  organizations  to  understand  and  address 
their  information  security  risks.  OCTAVE  is  led  by  a  small,  interdisciplinary  team  of  an  or¬ 
ganization’s  personnel  and  focuses  on  an  organization’s  assets  and  the  risks  to  those  assets.  It 
is  a  comprehensive,  systematic,  context-driven,  and  self-directed  evaluation  approach.  The 
essential  elements  of  the  OCTAVE  approach  are  embodied  in  a  set  of  criteria  that  define  the 
requirements  for  OCTAVE.  This  report  describes  the  OCTAVE  criteria.  The  goal  of  this  re¬ 
port  is  to  define  a  general  approach  for  evaluating  and  managing  information  security  risks. 
Organizations  can  then  develop  methods  that  are  consistent  with  the  OCTAVE  criteria. 


Operationally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation  and  OCTAVE  are  service  marks 
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1  Introduction 


Security  is  a  complex  discipline  with  both  organizational  and  technological  components. 
Consider  the  following  scenario.  A  financial  organization  is  required  to  protect  the  privacy  of 
its  customers.  The  company’s  security  policy  explicitly  requires  role-based  access  to  informa¬ 
tion.  Management  has  made  a  large  investment  in  technology  to  ensure  that  the  organization 
complies  with  its  security  policy.  For  example,  all  major  systems  have  access  control  mecha¬ 
nisms  to  restrict  access  to  system  resources.  When  people  start  to  work  for  the  company,  they 
are  assigned  access  to  system  resources  based  on  their  job  responsibilities.  Compliance  with 
the  access  control  policy  is  enforced  through  technological  mechanisms. 

However,  when  people  leave  the  company,  their  access  to  systems  is  rarely  terminated.  Even 
though  these  people  no  longer  have  roles  with  the  company,  they  can  access  its  systems  and 
sensitive  financial  information.  In  addition,  when  people  change  jobs  within  the  company, 
they  not  only  acquire  additional  access  privileges  for  the  new  jobs,  they  also  keep  the  access 
privileges  from  their  old  jobs.  While  procedures  require  that  employees  be  given  appropriate 
access  when  they  move  from  one  job  classification  to  another,  those  procedures  do  not  re¬ 
quire  revoking  access  rights  that  are  no  longer  necessary.  Some  people  who  have  been  work¬ 
ing  at  the  company  for  many  years  can  access  just  about  anything  they  want.  Even  though  the 
company  has  the  technological  means  for  enforcing  role-based  access  to  information  and  sys¬ 
tems,  organizational  practices  and  incomplete  procedures  make  this  fact  irrelevant. 

Think  about  how  much  you  rely  upon  access  to  information  and  systems  to  do  your  job.  To¬ 
day,  information  systems  are  essential  to  most  organizations  because  virtually  all  information 
is  captured,  stored,  and  accessed  in  digital  form.  We  rely  on  digital  data  that  are  accessible, 
dependable,  and  protected  from  misuse.  Systems  are  interconnected  in  ways  that  could  not  be 
imagined  10  years  ago.  Networked  systems  have  enabled  unprecedented  access  to  informa¬ 
tion.  Unfortunately,  they  have  also  exposed  our  information  to  a  variety  of  new  threats.  Or¬ 
ganizations  need  approaches  that  enable  them  to  understand  their  information  risks  and  create 
strategies  to  address  those  risks. 

The  Operationally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation^^  (OCTAVE^'^)  en¬ 
ables  an  organization’s  personnel  to  sort  through  the  complex  web  of  organizational  and 
technological  issues  to  understand  and  address  its  information  security  risks.  OCTAVE 


Operationally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation  and  OCTAVE  are  service  marks 
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defines  an  approach  to  information  security  risk  evaluations  that  is  comprehensive,  system¬ 
atic,  context  driven,  and  self  directed.  The  approach  requires  a  small,  interdisciplinary  analy¬ 
sis  team  of  business  and  information  technology  personnel  from  the  organization  to  lead  its 
evaluation  process. 

The  essential  elements,  or  requirements,  of  the  OCTAVE  approach  arc  embodied  in  a  set  of 
criteria.  There  can  be  many  methods  consistent  with  these  criteria,  but  there  is  only  one  set  of 
OCTAVE  criteria.  At  this  point,  we  have  developed  one  method  consistent  with  the  criteria. 
That  method,  which  we  documented  in  the  OCTAVE  Method  Implementation  Guide,  v2.0 
[Alberts  Ola],  was  designed  with  large  organizations  in  mind.  We  are  presently  developing  a 
method  for  small  organizations.  In  addition,  others  might  define  methods  for  specific  con¬ 
texts  that  are  consistent  with  the  criteria.  Figure  I  illustrates  these  points. 


OCTAVE 

Criteria 


OCTAVE  Method 

(as  defined  In  OCTAVE 
Method  Implementation 
Guide  v2.0) 

Developed  by  the  SEI 

!  An  OCTAVE-Consistent 
!  Method  for  Small  Organizations 


Under  development  by  the  SEI 


V4V 


Other  Methods  Consistent 
with  the  OCTAVE  Criteria 


Developed  by  others 


Figure  1:  Multiple  Methods  Consistent  with  the  OCTAVE  Criteria 

Next,  we  present  some  background  information  about  how  we  arrived  at  the  need  for  a  set  of 
criteria. 
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1.1  Background 

In  June  1999,  we  published  a  technical  report  describing  the  Operationally  Critical  Threat, 
Asset,  and  Vulnerability  Evaluation  (OCTAVE)  Framework  [Alberts  99].  The  framework  was 
a  specification  for  an  information  security  risk  evaluation  targeted  at  large  organizations.  The 
technical  report  featured  a  dataflow  diagram  that  specified  the  components  of  an  information 
security  risk  evaluation:  a  set  of  eight  processes,  each  with  required  inputs,  activities,  and 
outputs.  The  development  of  the  framework  was  based  upon  our  extensive  involvement  in  the 
development  and  delivery  of  the  proprietary  Information  Security  Evaluation  (ISE)  and,  ear¬ 
lier,  the  Software  Risk  Evaluation  (SRE)  [Williams  99].  Both  techniques  were  developed 
previously  at  the  Software  Engineering  Institute.  As  we  designed  the  framework,  we  also  in¬ 
corporated  the  results  of  our  research  into  information  security  risk  evaluations  that  were  be¬ 
ing  conducted  throughout  the  community. 

When  we  first  started  developing  the  framework,  our  goal  was  to  define  the  requirements  for 
a  general  approach  for  evaluating  and  managing  information  security  risks.  However,  we  re¬ 
alized  that  a  general  approach  implemented  in  a  small  organization  of  10  employees  would 
look  different  than  that  in  a  multinational  corporation.  Thus,  we  believed  that  we  needed  to 
examine  both  extremes  before  we  could  define  the  requirements  for  a  general  evaluation  ap¬ 
proach. 


We  designed  the  OCTAVE  Method  with  large  organizations  in  mind,  using  the  OCTAVE 
Framework  as  a  starting  point  for  the  method.  A  second  method,  targeted  at  small  organiza¬ 
tions,  is  evolving  from  the  OCTAVE  Method.  The  development  and  testing  of  these  methods 
helped  us  to  identify  the  common  (or  essential)  requirements  of  the  OCTAVE  approach  and 
has  led  to  the  refinement  of  the  framework  into  the  OCTAVE  criteria. 

1.2  Purpose 

This  technical  report  documents  the  OCTAVE  criteria.  Our  goal  in  writing  this  document  is  to 
define  a  general  approach  for  evaluating  and  managing  information  security  risks.  We  en¬ 
courage  organizations  to  develop  methods  that  are  consistent  with  the  OCTAVE  criteria.* 

This  document  does  not  provide  specific  implementation  details  about  any  method.  For  de¬ 
tailed  information  on  the  OCTAVE  Method,  see  the  OCTAVE  Method  Implementation  Guide, 
v2.0. 


^  Organizations  wishing  to  use  the  OCTAVE  name  with  their  products  or  services  should  contact  the 
Software  Engineering  Institute’s  licensing  agent. 
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This  report  is  organized  as  follows: 


Section  2  provides  an  overview  of  the  OCTAVE  approach. 

Section  3  introduces  the  structure  of  the  OCTAVE  criteria. 

Section  4  addresses  the  principles  of  OCTAVE. 

Section  5  addresses  the  OCTAVE  attributes. 

Section  6  addresses  the  OCTAVE  outputs. 

Section  7  provides  a  summary. 

Appendix  A  provides  an  example  set  of  activities  that  produce  the  required  outputs  of 
OCTAVE. 


Appendix  B  shows  the  relationship  between  the  OCTAVE  criteria  and  the  OCTAVE 
Method. 
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2  What  Is  OCTAVE? 


An  information  security  risk  evaluation  must  handle  both  organizational  and  technological 
issues  to  be  effective.  It  must  address  the  computing  infrastructure  as  well  as  how  people  use 
the  infrastructure  as  a  part  of  their  jobs.  Thus,  an  evaluation  needs  to  incorporate  the  context 
in  which  people  use  the  infrastructure  to  meet  the  business  objectives  of  the  organization,  as 
well  as  technological  security  issues  related  to  the  infrastructure. 

2.1  Key  Concepts 

We  view  using  information  security  risk  evaluations  to  improve  an  organization’s  security 
posture  as  a  sound  business  practice.  Since  most  organizations  rely  upon  access  to  electronic 
data  to  conduct  business,  the  data  need  to  be  adequately  protected  from  misuse.  The  ability  of 
an  organization  to  achieve  its  mission  and  meet  its  business  objectives  is  directly  linked  to  the 
state  of  the  computing  infrastructure  and  to  the  manner  in  which  people  interact  with  the  in¬ 
frastructure.  For  an  organization  to  be  in  the  best  position  to  achieve  its  mission,  its  people 
need  to  understand  which  information-related  assets  are  important,  as  well  as  what  they 
should  be  doing  to  protect  those  assets.  In  other  words,  people  in  the  organization  need  to  be 
involved  in  the  evaluation. 

OCTAVE  is  a  self-directed  information  security  risk  evaluation.  This  core  concept  of 
OCTAVE  is  defined  as  a  situation  where  people  from  an  organization  manage  and  direct  an 
information  security  risk  evaluation  for  their  organization.  The  organization’s  people  direct 
risk  evaluation  activities  and  are  responsible  for  making  decisions  about  the  organization’s 
efforts  to  improve  information  security.  In  OCTAVE,  an  interdisciplinary  team,  called  the 
analysis  team,  leads  the  evaluation. 


The  analysis  team  includes  people  from  both  the  business  units  and  the  information  technol¬ 
ogy  (IT)  department,  because  information  security  includes  both  business-  and  technology- 
related  issues.  People  from  the  business  units  of  an  organization  understand  what  information 
is  important  to  complete  their  tasks  as  well  as  how  they  access  and  use  the  information.  The 
information  technology  staff  understands  issues  related  to  how  the  computing  infrastructure 
is  configured,  as  well  as  what  is  important  to  keep  it  running.  Both  of  these  perspectives  are 
important  in  understanding  the  global,  organizational  view  of  information  security  risk. 


Risk  is  the  possibility  of  suffering  harm  or  loss.  It  breaks  down  into  three  basic  components: 
asset,  threat,  and  vulnerability.  Thus,  an  information  security  risk  evaluation  must  account  for 
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all  three  components  of  risk.  OCTAVE  is  an  assci-driven  evaluation  approach.  It  requires  an 
analysis  team  to 

•  identify  information-related  assets  (e.g..  information  and  systems)  that  are  important  to 
the  organization 

•  focus  risk  analysis  activities  on  those  assets  judged  to  be  most  critical  to  the  organization 

OCTAVE  requires  the  analysis  team  to  consider  the  relationships  among  critical  assets,  the 
threats  to  those  assets,  and  vulnerabilities  (both  organizational  and  technological)  that  can 
expose  assets  to  threats.  It  requires  the  analysis  team  to  evaluate  risks  in  an  operational  con¬ 
text.  In  other  words,  OCTAVE  focuses  on  how  operational  systeins  are  used  to  conduct  an 
organization’s  business  and  how  those  systems  are  at  risk  due  to  security  threats. 


When  a  team  completes  an  OCTAVE,  it  creates  a  protection  strategy  for  organizational  im¬ 
provement  and  risk  mitigation  plans  to  reduce  the  risk  to  the  organization’s  critical  assets. 
Thus,  OCTAVE  incorporates  both  strategic  and  tactical  views  of  risk. 

2.2  Three  Aspects  -  Three  Phases 

The  organizational,  technological,  and  analysis  aspects  of  an  information  security  risk  evalua¬ 
tion  lend  it  to  a  three-phased  approach.  OCTAVE  is  organized  around  these  basic  aspects  (il¬ 
lustrated  in  Figure  2),  enabling  organizational  personnel  to  assemble  a  comprehensive  picture 
of  the  organization’s  information  security  needs.  In  Section  6  of  this  document,  we  explore 
the  phases  of  OCTAVE  in  greater  detail.  The  phases  are 

•  Phase  I:  Build  Asset-Based  Threat  Profiles  -  This  is  an  organizational  evaluation.  Staff 
members  from  the  organization  contribute  their  perspectives  on  what  is  important  to  the 
organization  (information-related  assets)  and  what  is  currently  being  done  to  protect 
those  assets.  The  analysis  team  consolidates  the  information  and  selects  the  assets  that  are 
most  important  to  the  organization  (critical  assets).  The  team  then  describes  security  re¬ 
quirements  for  the  critical  assets  and  identifies  threats  to  the  critical  assets,  creating  threat 
profiles. 

•  Phase  2:  Identify  Infrastructure  Vulnerabilities  -  This  is  an  evaluation  of  the  information 
infrastructure.  The  analysis  team  identifies  key  information  technology  systems  and 
components  that  are  related  to  each  critical  asset.  The  team  then  examines  the  key  com¬ 
ponents  for  weaknesses  (technology  vulnerabilities)  that  can  lead  to  unauthorized  action 
against  critical  assets. 

•  Phase  3:  Develop  Security  Strategy  and  Plans  -  During  this  part  of  the  evaluation,  the 
analysis  team  identifies  risks  to  the  organization’s  critical  assets  and  decides  what  to  do 
about  them.  The  team  creates  a  protection  strategy  for  the  organization  and  mitigation 
plans  to  address  the  risks  to  the  critical  assets,  based  upon  an  analysis  of  the  information 
gathered. 
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■Critical  Assets 
■Security  Requirements  for 
Critical  Assets 
■Threats  to  Critical  Assets 
■Current  Security  Practices 
■Current  Organizational 
Vulnerabilities 


Phase  3: 

Develop  Security 
Strategy  and  Plans 


“Risks  to  Critical  Assets 
■Risk  Measures 


■Protection  Strategy 
■Risk  Mitigation  Plans 


■Key  Components 
■Current  Technology 
Vulnerabilities 


Figure  2:  OCTAVE  Phases 

2.3  Part  of  a  Continuum 

OCTAVE  provides  an  organization-wide  view  of  the  current  information  security  risks.  It 
provides  a  snapshot  in  time,  or  a  baseline,  that  can  be  used  to  focus  mitigation  and  improve¬ 
ment  activities.  During  OCTAVE,  an  analysis  team  performs  activities  to 

•  identify  the  organization’s  information  security  risks 

•  analyze  the  risks  to  determine  priorities 

•  plan  for  improvement  by  developing  a  protection  strategy  for  organizational  improve¬ 
ment  and  risk  mitigation  plans  to  reduce  the  risk  to  critical  organizational  assets 

An  organization  will  not  improve  unless  it  implements  its  plans.  These  improvement  activi¬ 
ties  are  performed  after  OCTAVE  has  been  completed.  After  OCTAVE,  the  analysis  team,  or 
other  designated  personnel 

•  plan  how  to  implement  the  protection  strategy  and  risk  mitigation  plans  by  developing 
detailed  action  plans.  This  activity  can  include  a  detailed  cost-benefit  analysis  among 
strategies  and  actions,  and  it  results  in  detailed  implementation  plans. 
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•  implement  the  detailed  action  plans 

•  monitor  the  action  plans  for  schedule  and  for  effectiveness.  This  activity  includes  moni¬ 
toring  risks  for  any  changes. 

•  control  variations  in  plan  execution  by  taking  appropriate  corrective  actions 
Note  that  these  activities  are  nothing  more  than  a  plan-do-check-act  cycle. 

An  information  security  risk  evaluation  is  part  of  an  organization’s  information  security  risk 
management  activities.  OCTAVE  is  the  evaluation  activity,  not  the  continuous  process.  Thus, 
it  has  a  defined  beginning  and  end.  Figure  3  shows  the  relationship  among  these  activities 
and  where  OCTAVE  fits  in.  In  addition,  you  should  note  that  there  is  a  continuous  aspect  to 
the  Identify  and  Analyze  activities. 


''^p/ement 


Figure  3:  OCTA  VE  and  Risk  Management  Activities 

Periodically,  an  organization  will  need  to  “reset”  its  baseline  by  conducting  another 
OCTAVE.  The  time  between  evaluations  can  be  predetermined  (e.g.,  yearly)  or  triggered  by 
major  events  (e.g.,  corporate  reorganization  or  redesign  of  an  organization’s  computing  infra¬ 
structure).  In  between  evaluations,  an  organization  can  periodically  identify  new  risks,  ana¬ 
lyze  these  risks  in  relation  to  existing  risks,  and  develop  mitigation  plans  for  them. 


8 


CMU/SE1-2001-TR-016 


2.4  Business  and  Security  Practices 

To  meet  its  business  objectives,  each  organization  implements  a  unique  set  of  business  prac¬ 
tices.  Because  OCTAVE  examines  the  link  between  organizational,  or  business,  issues  and 
technological  issues,  the  information  that  an  analysis  team  gathers  and  the  recommendations 
that  it  makes  can  affect  other  organizational  business  practices.  For  example,  one  organiza¬ 
tion  that  performed  an  OCTAVE  identified  an  action  to  summarize  the  results  of  the  evalua¬ 
tion  and  include  the  summary  as  input  to  its  strategic  planning  process.  Many  such  links  ex¬ 
ist;  however,  it  is  beyond  the  scope  of  this  document  to  directly  address  them. 

Finally,  we  do  want  to  stress  one  point  about  how  business  practices  are  implemented  in  or¬ 
ganizations.  Although  many  business  practices  tend  to  be  similar,  the  specific  ways  in  which 
practices  are  implemented  in  different  organizations  vary  based  on  the  characteristics  of  the 
organizations.  Consider  the  differences  in  management  practices  at  a  small  start-up  company 
in  contrast  to  the  practices  required  in  a  large,  established  organization.  Both  organizations 
require  a  set  of  similar  management  practices  (e.g.,  planning,  budgeting),  but  the  practices  are 
implemented  differently.  Similarly,  we  have  found  that  the  way  in  which  organizations  im¬ 
plement  an  information  security  risk  evaluation  practice  differs  based  on  a  variety  of  organ¬ 
izational  factors.  OCTAVE  implemented  in  a  large  multinational  corporation  is  different  than 
OCTAVE  in  a  small  start-up  organization.  However,  there  are  required  outputs  and  attributes 
of  the  OCTAVE  approach  that  remain  the  same  across  organizational  types.  In  this  document, 
we  define  those  requirements  in  the  form  of  a  set  of  criteria.  In  the  next  section,  we  highlight 
the  structure  of  the  OCTAVE  criteria. 
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3  Structure  of  the  OCTAVE  Criteria 


The  OCTAVE  criteria  are  a  set  of  principles,  attributes,  and  outputs.  Principles  are  the  fun¬ 
damental  concepts  driving  the  nature  of  the  evaluation.  They  define  the  philosophy  that 
shapes  the  evaluation  process.  For  example,  self  direction  is  one  of  the  principles  of 
OCTAVE.  The  concept  of  self  direction  means  that  people  inside  the  organization  are  in  the 
best  position  to  lead  the  evaluation  and  make  decisions. 


The  requirements  of  the  evaluation  are  embodied  in  the  attributes  and  outputs.  Attributes  are 
the  distinctive  qualities,  or  characteristics,  of  the  evaluation.  They  are  the  requirements  that 
define  the  basic  elements  of  the  OCTAVE  approach  and  define  what  is  necessary  to  make  the 
evaluation  a  success  from  both  the  process  and  organizational  perspectives.  Attributes  are 
derived  from  the  OCTAVE  principles.  For  example,  one  of  the  attributes  of  OCTAVE  is  that 
an  interdisciplinary  team  (the  analysis  team)  staffed  by  personnel  from  the  organization  lead 
the  evaluation.  The  principle  behind  the  creation  of  an  analysis  team  is  self  direction. 


Finally,  outputs  are  the  required  results  of  each  phase  of  the  evaluation.  They  define  the  out¬ 
comes  that  an  analysis  team  must  achieve  during  each  phase.  We  recognize  that  there  is  more 
than  one  set  of  activities  that  can  produce  the  outputs  of  OCTAVE.  It  is  for  this  reason  that 
we  do  not  specify  one  set  of  required  activities.  However,  in  Appendix  A  of  this  document, 
we  present  a  set  of  activities  that  can  be  used  to  produce  the  required  outputs. 

Table  1,  on  the  next  page,  highlights  the  OCTAVE  criteria.  In  the  remainder  of  this  document, 
we  formally  define  each  principle,  attribute,  and  output. 
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Table  1:  The  OCTAVE  Criteria 
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4  Principles  of  OCTAVE 


Principles  are  the  fundamental  concepts  that  define  the  philosophy  behind  the  evaluation 
process.  They  shape  the  evaluation  approach  and  provide  the  basis  for  the  evaluation  process. 
We  have  grouped  the  principles  into  the  following  three  areas: 

•  Information  Security  Risk  Evaluation  Principles:  These  are  key  aspects  that  form  the 
foundation  of  effective  information  security  risk  evaluations. 

-  self  direction 

-  adaptable  measures 

-  defined  process 

“  foundation  for  a  continuous  process 

•  Risk  Management  Principles:^  These  are  basic  principles  common  to  effective  risk  man¬ 
agement  practices. 

-  forward-looking  view 

-  focus  on  the  critical  few 

-  integrated  management 

•  Organizational  and  Cultural  Principles'?  These  are  aspects  of  the  organization  and  its 
culture  that  are  essential  to  the  successful  management  of  information  security  risks. 

-  open  communication 

-  global  perspective 

-  teamwork 

The  principles  are  shown  graphically  in  Figure  4. 


“  These  principles  are  similar  in  scope  and  intent  to  those  documented  in  the  Continuous  Risk  Man¬ 
agement  Guidebook  [Dorofee  96]. 
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Organizational  and  Cultural  Principles 

■  open  communication 

■  global  perspective 

■  teamwork 

i  1 

1  Risk  Management  Principles  1 

1 

1 

1 

■  forward-looking  view 

1 

■  focus  on  the  critical  few 

1 

i 

i 

1 

i 

i 

■  integrated  monagement 

1 

i 

Information  Security  Risk  Evaluation  Principles  ; 

1 

1 

■  self  direction  1 

1 

1 

■  odaptable  measures  ; 

1 

1 

■  defined  process  ; 

1 

■  foundation  for  a  i 

f 

t 

continuous  process  1 

1 

j 

_ J 

Figure  4:  The  Principles  of  OCTAVE 

4.1  Information  Security  Risk  Evaluation  Principles 

In  this  section,  we  focus  on  principles  that  form  the  basis  of  effective  information  security 
risk  evaluations,  starting  with  self  direction. 

Self  Direction 

Self  direction  describes  a  situation  where  people  in  an  organization  manage  and  direct  infor¬ 
mation  security  risk  evaluations  for  their  organization.  These  people  are  responsible  for  di¬ 
recting  the  risk  management  activities  and  for  making  decisions  about  the  organization’s  se¬ 
curity  efforts.  Self  direction  requires 

•  taking  responsibility  for  information  security  by  leading  the  information  security  risk  as¬ 
sessment  and  managing  the  evaluation  process 

•  making  the  final  decisions  about  the  organization’s  security  efforts,  including  which 
improvements  and  actions  to  implement 
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Adaptable  Measures 

A  flexible  evaluation  process  can  adapt  to  changing  technology  and  advancements.  It  is  not 
constrained  by  a  rigid  model  of  current  sources  of  threats  or  by  what  practices  are  currently 
accepted  as  “best.’'  Because  the  information  security  and  information  technology  domains 
change  very  rapidly,  an  adaptable  set  of  measures  against  which  an  organization  can  be 
evaluated  is  essential.  Adaptable  measures  require 

•  current  catalogs  of  information  that  define  accepted  security  practices,  known  sources  of 
threat,  and  known  technological  weaknesses  (vulnerabilities) 

•  an  evaluation  process  that  can  accommodate  changes  to  the  catalogs  of  information 

Defined  Process 

A  defined  process  describes  the  need  for  information  security  evaluation  programs  to  rely 
upon  defined  and  standardized  evaluation  procedures.  Using  a  defined  evaluation  process  can 
help  to  institutionalize  the  process,  ensuring  some  level  of  consistency  in  the  application  of 
the  evaluation.  A  defined  process  requires 

•  assigning  responsibilities  for  conducting  the  evaluation 

•  defining  all  evaluation  activities 

•  specifying  all  tools,  worksheets,  and  catalogs  of  information  required  by  the  evaluation 

•  creating  a  common  format  for  documenting  the  evaluation  results 

Foundation  for  a  Continuous  Process 

An  organization  must  implement  practice-based  security  strategies  and  plans  to  improve  its 
security  posture  over  time.  By  implementing  these  practice-based  solutions,  an  organization 
can  start  institutionalizing  good  security  practices,  making  them  part  of  the  way  the  organiza¬ 
tion  routinely  conducts  business.  Security  improvement  is  a  continuous  process,  and  the  re¬ 
sults  of  an  information  security  risk  evaluation  provide  the  foundation  for  continuous  im¬ 
provement.  A  foundation  for  a  continuous  process  requires 

•  identifying  information  security  risks  using  a  defined  evaluation  process 

•  implementing  the  results  of  information  security  risk  evaluations 

•  setting  up  the  ability  to  manage  information  security  risks  over  time 

•  implementing  security  strategies  and  plans  that  incorporate  a  best-practice  approach  to 
security  improvement 
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4.2  Risk  Management  Principles 

Next,  we  look  at  broader  principles  that  focus  on  concepts  common  to  effective  risk  man¬ 
agement  approaches. 

Forward-Looking  View 

A  forward-looking  view  requires  an  organization’s  personnel  to  look  beyond  the  current 
problems  by  focusing  on  risks  to  the  organization’s  most  critical  assets.  The  focus  is  on  man¬ 
aging  uncertainty  by  exploring  the  interrelationships  among  assets,  threats,  and  vulnerabili¬ 
ties,  and  exploring  the  resulting  impact  on  the  organization's  mission  and  business  objectives. 
A  forward-looking  view  requires 

•  thinking  about  tomorrow,  focusing  on  managing  the  uncertainty  presented  by  a  range  of 
risks 

•  managing  organizational  resources  and  activities  by  incorporating  the  uncertainty  pre¬ 
sented  by  information  security  risks 

Focus  on  the  Critical  Few 

This  principle  requires  the  organization  to  focus  on  the  most  critical  information  security  is¬ 
sues.  Every  organization  faces  constraints  on  the  number  of  staff  members  and  funding  that 
can  be  used  for  information  security  activities.  Thus,  the  organization  must  ensure  that  it  is 
applying  its  resources  efficiently,  both  during  an  information  security  risk  evaluation  and  af¬ 
terwards.  A  focus  on  the  critical  few  requires 

•  using  targeted  data  collection  to  collect  information  about  security  risks 

•  identifying  the  organization’s  most  critical  assets  and  selecting  security  practices  to  pro¬ 
tect  those  assets 

Integrated  Management 

This  principle  requires  that  security  policies  and  strategies  be  consistent  with  organizational 
policies  and  strategies.  The  organization’s  management  proactively  considers  tradeoffs 
among  business  and  security  issues  when  creating  policy,  striking  a  balance  between  business 
and  security  goals.  Integrated  management  requires 

•  integrating  information  security  issues  in  the  organization’s  business  processes 

•  considering  business  strategies  and  goals  when  creating  and  revising  information  security 
strategies  and  policies 
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4.3  Organizational  and  Cultural  Principles 

Finally,  we  examine  the  principles  that  help  to  create  an  organizational  culture  that  is  condu¬ 
cive  to  effective  risk  management. 

Open  Communication 

Information  security  risk  management  cannot  succeed  without  open  communication  of  secu¬ 
rity-related  issues.  Information  security  risks  cannot  be  addressed  if  they  aren’t  communi¬ 
cated  to  and  understood  by  the  organization’s  decision  makers.  A  fundamental  concept  behind 
most  successful  risk  management  programs  is  a  culture  that  supports  open  communication  of 
risk  information  through  a  collaborative  evaluation  approach.  Often,  evaluation  methods  pro¬ 
vide  staff  members  with  ways  of  expressing  information  so  that  the  information  is  not  attrib¬ 
uted  to  them,  allowing  for  a  free  expression  of  ideas.  Open  communication  requires 

•  evaluation  activities  that  are  built  upon  collaborative  approaches  (e.g.,  workshops) 

•  encouraging  exchanges  of  security  and  risk  information  among  all  levels  of  an  organiza¬ 
tion 

•  using  consensus-based  processes  that  value  the  individual  voice 

Global  Perspective 

This  principle  requires  members  of  the  organization  to  create  a  common  view  of  what  is  most 
important  to  the  organization.  Individual  perspectives  pertaining  to  information  security  risk 
are  solicited  and  then  consolidated,  creating  a  global  picture  of  the  information  security  risks 
with  which  the  organization  must  deal.  A  global  perspective  requires 

•  identifying  the  multiple  perspectives  of  information  security  risk  that  exist  in  the  organi¬ 
zation 

•  viewing  information  security  risk  within  the  larger  context  of  the  organization’s  mission 
and  business  objectives 

Teamwork 

No  individual  can  understand  all  of  the  information  security  issues  facing  an  organization. 
Information  security  risk  management  requires  an  interdisciplinary  approach,  including  both 
business  and  information  technology  perspectives.  Teamwork  requires 

•  creating  an  interdisciplinary  team  to  lead  the  evaluation 

•  knowing  when  to  include  additional  perspectives  in  the  evaluation  activities 

•  working  cooperatively  to  complete  evaluation  activities 

•  leveraging  people’s  talents,  skills,  and  knowledge 
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The  principles  that  we  defined  in  this  section  are  broad  concepts  that  form  the  foundation  for 
information  security  risk  evaluation  activities.  Next,  we  examine  how  these  concepts  are  im¬ 
plemented  in  an  evaluation  approach  by  focusing  on  the  attributes  of  OCTAVE. 
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5  OCTAVE  Attributes 


Attributes  are  the  distinctive  qualities,  or  characteristics,  of  the  evaluation.  They  form  the 
requirements  of  the  OCTAVE  approach  and  define  what  is  necessary  to  make  the  evaluation  a 
success  from  both  the  process  and  organizational  perspectives.  Each  OCTAVE  attribute  is 
defined  using  the  following: 

•  requirements  -  the  essential  elements  of  the  attribute 

•  importance  -  why  the  attribute  is  important  to  the  evaluation  process 

5.1  Relationship  Between  OCTAVE  Attributes  and 
Principles 

Earlier  in  this  report,  we  indicated  that  the  principles  of  OCTAVE  shape  the  nature  of  the  at¬ 
tributes.  Table  2  illustrates  the  primary  relationships  between  the  principles  and  attributes. 
Note  that  each  attribute  is  numbered  for  easy  cross-referencing.  In  the  next  section,  we  define 
each  attribute,  beginning  with  RA.l,  Analysis  Team. 
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Table  2:  Mapping  OCTAVE  Principles  to  Attributes 


Mapping  of  Principles  to  Attributes 

Principle 

Attribute 

Self  Direction 

RA.l  Analysis  Team 

RA.2  Augmenting  Analysis  Team  Skills 

Adaptable  Measures 

RA.3  Catalog  of  Practices 

RA.4  Generic  Threat  Profile 

RA.5  Catalog  of  Vulnerabilities 

Defined  Process 

RA.6  Defined  Evaluation  Activities 

RAJ  Documented  Evaluation  Results 

RA.8  Evaluation  Scope 

Foundation  for  a  Continuous 
Process 

RA.9  Next  Steps 

RAJ  Catalog  of  Practices 

Forward-Looking  View 

RA.  10  Focus  on  Risk 

Focus  on  the  Critical  Few 

RA.8  Evaluation  Scope 

RA.  1 1  Focused  Activities 

Integrated  Management 

RA.l 2  Organizational  and  Technological  Issues 

RA.l 3  Business  and  Information  Technology  Participation 

RA.  14  Senior  Management  Participation 

Open  Communication 

RA.15  Collaborative  Approach 

Global  Perspective 

RA.12  Organizational  and  Technological  Issues 

RA.13  Business  and  Information  Technology  Participation 

Teamwork 

RA.l  Analysis  Team 

RA.2  Augment  Analysis  Team  Skills 

RA.  13  Business  and  Information  Technology  Participation 

RA.15  Collaborative  Approach 
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5.2  Attribute  Requirements 
Analysis  Team  (RA.1) 

Requirements  An  analysis  team  staffed  by  personnel  from  the  organization  must 

lead  the  evaluation  activities.  The  analysis  team  must  be  interdisci¬ 
plinary  in  nature,  including  people  from  both  the  business  units  and 
the  information  technology  department.  The  analysis  team  must 
manage  and  direct  the  information  security  risk  evaluation  for  its 
organization,  and  it  must  be  responsible  for  making  decisions  based 
on  the  information  gathered  during  the  evaluation  process. 


Importance  This  attribute  is  important  because  it  ensures  that  ultimate  responsi¬ 

bility  for  conducting  the  evaluation  is  assigned  to  a  team  of  individu¬ 
als  from  the  organization.  Using  an  analysis  team  to  lead  the  evalua¬ 
tion  helps  to  ensure  that 

•  people  who  understand  the  business  processes  and  who  under¬ 
stand  information  technology  work  together  to  improve  the  or¬ 
ganization’s  security  posture 

•  the  evaluation  is  run  by  personnel  who  understand  how  to  apply 
all  worksheets  and  tools  used  during  the  evaluation 

•  the  method  is  applied  consistently  across  the  organization 

•  people  in  the  organization  feel  “ownership”  of  the  evaluation 
results,  making  them  more  likely  to  implement  the  recommended 
strategies  and  plans 
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Augmenting  Analysis  Team  Skills  (RA.2) 

Requirements  The  evaluation  process  must  allow  the  analysis  team  to  augment  its 

skills  and  abilities  by  including  additional  people  who  have  specific 
skills  required  by  the  process  or  who  possess  required  expertise. 
These  additional  people  can  be  from  other  parts  of  the  organization, 
or  they  can  be  from  an  external  organization. 


Importance  The  analysis  team  is  responsible  for  analyzing  information  and  mak¬ 

ing  decisions  during  the  evaluation.  However,  the  core  members  of 
the  analysis  team  may  not  have  all  of  the  knowledge  and  skills 
needed  during  the  evaluation.  At  each  point  in  the  process,  the  analy¬ 
sis  team  members  must  decide  if  they  need  to  augment  their  knowl¬ 
edge  and  skills  for  a  specific  task.  They  can  do  so  by  including  others 
in  the  organization  or  by  using  external  experts.  This  attribute  is  im¬ 
portant  because  it  ensures  that  the  analysis  team  has  the  required 
skills  and  knowledge  to  complete  the  evaluation.  This  attribute  also 
allows  an  organization  to  conduct  an  information  security  risk 
evaluation  even  when  it  does  not  have  all  of  the  required  knowledge 
and  skills  within  the  organization.  Thus,  it  provides  an  avenue  for 
working  with  external  experts  when  appropriate. 
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Catalog  of  Practices  (RA.3) 

Requirements  The  evaluation  process  must  assess  an  organization’s  security  prac¬ 

tices  by  considering  a  range  of  strategic  and  operational  security 
practice  areas.  These  are  formally  defined  in  a  catalog  of  practices. 
(An  example  can  be  found  in  the  OCTAVE  Catalog  of  Practices  [Al¬ 
berts  01b].)  The  catalog  of  practices  used  by  an  organization  must  be 
consistent  with  all  laws,  regulations,  and  standards  of  due  care  with 
which  the  organization  must  comply. 


Strategic  practices  focus  on  organizational  issues  at  the  policy  level 
and  provide  good,  general  management  practices.  They  address  busi¬ 
ness-related  issues,  as  well  as  issues  that  require  organization-wide 
plans  and  participation.  Since  strategic  practices  are  based  on  good 
management  practice,  they  should  be  fairly  stable  over  time.  The  fol¬ 
lowing  list  provides  an  example  of  typical  strategic  practice  areas: 

•  Security  Awareness  and  Training  addresses  how  well  security- 
related  practices  are  understood  by  general  staff  members  and  in¬ 
formation  technology  staff  members.  One  way  to  enhance  the 
staff’s  understanding  of  information  security  practice  is  through 
training  and  education. 

•  Security  Strategy  focuses  on  the  integration  of  information  secu¬ 
rity  issues  into  the  business  strategy  of  the  organization. 

•  Security  Management  defines  information  security  roles  and  re¬ 
sponsibilities  as  well  as  management’s  support  for  information 
security  activities. 

•  Security  Policies  and  Regulations  addresses  the  organizational 
and  management  direction  for  information  security,  including 
which  mandated  regulations  must  be  met.  This  area  also  deals 
with  the  staff’s  understanding  of  policies  and  enforcement  of 
policies. 

•  Collaborative  Security  Management  focuses  on  good  practice 
when  working  with  third  parties  (contractors,  Internet  service 
providers,  managed  service  providers,  partners,  etc.). 

•  Contingency  Planning/Disaster  Recovery  addresses  plans  to 
counteract  disruptions  in  business  activities  and  in  systems  and 
networks. 

Operational  practices  focus  on  technology-related  issues  dealing  with 
how  people  use,  interact  with,  and  protect  technology.  They  are  sub¬ 
ject  to  changes  as  technology  advances  and  new  or  updated  practices 
arise  to  deal  with  those  changes.  The  following  list  provides  an  ex¬ 
ample  of  typical  operational  practice  areas: 
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•  Physical  Security 

-  Physical  Security  Plans  and  Procedures  focuses  on  whether 
physical  security  policies  and  procedures  for  the  facility  exist 
and  whether  they  have  been  tested. 

-  Physical  Access  Control  addresses  policies  and  procedures 
for  controlling  physical  assess  to  work  areas  and  to  informa¬ 
tion  technology  assets. 

-  Monitoring,  and  Auditing  Physical  Security  defines  an  or¬ 
ganization's  approach  for  ensuring  that  physical  security 
policies  and  procedures  are  implemented  and  are  effective. 

•  Information  Technology  Security 

-  System  and  Network  Management  focuses  on  practices  for 
the  secure  operation  of  information  technology  systems  and 
networks. 

-  System  Administration  Tools  focuses  on  tools  and  mecha¬ 
nisms  for  secure  system  and  network  administration. 

-  Monitoring  and  Auditing  IT  Security  defines  an  organiza¬ 
tion's  approach  for  ensuring  that  information  technology  se¬ 
curity  policies  and  procedures  are  implemented  and  are  ef¬ 
fective. 

-  Authentication  and  Authorization  includes  practices  for  veri¬ 
fying  users  to  systems  and  for  controlling  access  to  networks, 
systems,  and  applications. 

-  Vulnerability  Management  focuses  on  procedures  for  peri¬ 
odically  assessing  and  managing  technology  vulnerabilities. 

-  Encryption  addresses  security  practices  for  using  encryption 
to  protect  an  organization’s  data  during  data  storage  and 
transmission. 

-  Security  Architecture  and  Design  focuses  on  integrating  se¬ 
curity  into  the  formal  design  of  the  infrastructure’s  architec¬ 
ture  and  topology. 

•  Staff  Security 

-  Incident  Management  includes  practices  for  identifying,  re¬ 
porting,  and  responding  to  suspected  security  incidents  and 
violations. 

-  General  Staff  Practices  focuses  on  staff  members’  under¬ 
standing  of  their  security  roles  and  responsibilities  and  fol¬ 
lowing  security  policies  and  procedures. 
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Importance 


Using  a  catalog  of  practices  is  important  because  it  allows  an  organi¬ 
zation  to  evaluate  itself  against  a  known  and  accepted  measure.  This 
helps  the  organization  to  understand  what  it  is  currently  doing  well 
with  respect  to  security  (its  current  security  practices)  and  what  it  is 
not  doing  well  (its  organizational  vulnerabilities).  The  catalog  of 
practices  is  also  important  because  it  creates  the  structure  for  an  or¬ 
ganization’s  protection  strategy.  Finally,  the  catalog  provides  a  basis 
for  selecting  actions  to  include  in  risk  mitigation  plans. 
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Generic  Threat  Profile  (RA.4) 

Requirements  The  evaluation  process  must  assess  threats  to  the  organization's  criti¬ 

cal  assets  by  considering  a  broad  range  of  potential  threat  sources 
that  are  formally  defined  in  a  generic  threat  profile.  Typical  catego¬ 
ries  of  threat  include 

•  Human  Actors  Using  Network  Access  -  The  threats  in  this  cate¬ 
gory  are  network -based  threats  to  an  organization’s  critical  as¬ 
sets.  They  require  direct  action  by  a  person  and  can  be  deliberate 
or  accidental  in  nature. 

•  Human  Actors  Using  Physical  Access  -  The  threats  in  this  cate¬ 
gory  are  physical  threats  to  an  organization’s  critical  assets.  They 
require  direct  action  by  a  person  and  can  be  deliberate  or  acci¬ 
dental  in  nature. 

•  System  Problems  -  The  threats  in  this  category  are  problems  with 
an  organization’s  information  technology  systems.  Examples  in¬ 
clude  hardware  defects,  software  defects,  unavailability  of  re¬ 
lated  enterprise  systems,  malicious  code  (e.g.,  viruses,  Trojan 
horses),  and  other  system-related  problems. 

•  Other  Problems  -  The  threats  in  this  category  are  problems  or 
situations  that  are  outside  the  control  of  an  organization.  This 
category  of  threats  includes  natural  disasters  (such  as  floods, 
earthquakes,  and  storms)  that  can  affect  an  organization’s  infor¬ 
mation  technology  systems  as  well  as  interdependency  risks.  In¬ 
terdependency  risks  include  the  unavailability  of  critical  infra¬ 
structures  (telecommunications,  electricity,  etc.).  Other  types  of 
threats  outside  the  control  of  an  organization  can  also  be  in¬ 
cluded  here.  Examples  of  these  threats  are  power  outages  or  bro¬ 
ken  water  pipes. 


Importance  Using  a  generic  threat  profile  is  important  because  it  allows  an  or¬ 

ganization  to  identify  the  threats  to  its  critical  assets  based  on  known 
potential  sources  of  threat.  The  profile  also  uses  a  structured  way  of 
representing  potential  threats  and  yields  a  comprehensive  summary 
of  threats  to  critical  assets.  This  profile  is  important  because  it  pro¬ 
vides  a  complete  and  simple  way  to  record  and  communicate  threat 
information. 
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Catalog  of  Vulnerabilities  (RA.5) 

Requirements  The  evaluation  process  must  assess  the  technological  weaknesses 

(technology  vulnerabilities)  in  the  key  components  of  the  computing 
infrastructure  by  considering  a  range  of  technology  vulnerabilities 
based  on  platform  and  application.  Vulnerability  evaluation  tools 
(software,  checklists,  scripts)  examine  infrastructure  components  for 
technology  vulnerabilities  contained  in  the  catalog.  Two  examples  of 
catalogs  of  vulnerabilities  are 

•  CERT®  Knowledgebase^ 

•  Common  Vulnerabilities  and  Exploits  (CVE  Y 


Importance  Using  a  catalog  of  vulnerabilities  is  important  because  it  allows  an 

organization  to  evaluate  its  technology  base  against  known  technol¬ 
ogy  vulnerabilities.  Identifying  which  vulnerabilities  are  present  in 
the  organization’s  key  components  provides  the  organization  with 
information  about  how  vulnerable  its  computing  infrastructure  cur¬ 
rently  is. 


®  CERT  is  registered  in  the  U.S.  Patent  and  Trademark  Office. 

^  The  CERT®  Knowledgebase  contains  a  public  database  describing  vulnerabilities  and  a  restricted- 
access  catalog  containing  descriptive  information  regarding  more  than  1,300  vulnerabilities.  It  can 
be  accessed  at  <http://www.cert.org/kb/>. 

^  CVE  is  a  community  effort  led  by  the  MITRE  Corporation.  It  can  be  accessed  at 
<http://www.cve.mitre.org>. 
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Defined  Evaluation  Activities  (RA.6) 

Requirements  The  procedures  for  performing  each  evaluation  activity  and  the  arti¬ 

facts  used  during  each  activity  must  be  defined  and  documented. 

This  includes 

•  procedures  for  preparing  for  the  evaluation 

•  procedures  for  scoping  the  evaluation 

•  procedures  for  completing  each  evaluation  activity 

•  specifications  for  all  tools  and  worksheets  required  by  each  ac¬ 
tivity 

•  specifications  for  catalogs  of  information  that  define  accepted 
security  practices,  known  sources  of  threat,  and  known  techno¬ 
logical  weaknesses 

Importance  Implementing  defined  evaluation  activities  helps  to  institutionalize 

the  evaluation  process  in  the  organization,  ensuring  some  level  of 
consistency  in  the  application  of  the  process  [GAO  99].  It  also  pro¬ 
vides  a  basis  upon  which  the  activities  can  be  tailored  to  fit  the  needs 
of  a  particular  business  line  or  group. 


Documented  Evaluation  Results  (RA.7) 

Requirements  The  organization  must  document  the  results  of  the  evaluation,  either 

in  paper  or  electronic  form.  Organizations  typically  document  and 
archive  the  following  types  of  information: 

•  the  risks  to  the  organization’s  critical  assets 

•  security  strategies  and  plans  to  improve  the  organization’s  secu¬ 
rity  posture 

Importance  It  is  important  to  establish  a  permanent  record  of  evaluation  results. 

A  database  of  information  can  serve  as  source  material  for  subse¬ 
quent  evaluations  and  is  also  useful  when  tracking  the  status  of  plans 
and  actions  after  the  evaluation.  For  example,  the  information  that  is 
recorded  can  also  be  used  as  lessons  learned.  When  risks  to  a  critical 
asset  are  identified,  staff  members  can  look  at  the  mitigation  plans 
for  risks  to  similar  assets.  Organizational  personnel  can  understand 
which  mitigation  actions  have  been  effective  in  the  past  and  which 
haven’t.  This  can  help  them  to  create  more  effective  mitigation  plans. 
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Evaluation  Scope  (RA.8) 

Requirements  The  extent  of  each  evaluation  must  be  defined.  The  evaluation  proc¬ 

ess  must  include  guidelines  to  help  the  organization  decide  which 
operational  areas  (business  units)  to  include  in  the  evaluation. 


Importance  Setting  the  scope  of  an  evaluation  is  important  for  ensuring  that  the 

evaluation  results  are  useful  to  the  organization.  If  the  scope  of  an 
evaluation  becomes  too  broad,  it  is  often  difficult  to  analyze  all  of  the 
information  that  is  gathered.  Setting  a  manageable  scope  for  the 
evaluation  reduces  the  size  of  the  evaluation,  making  it  easier  to 
schedule  and  perform  the  activities.  In  addition,  the  areas  of  an  or¬ 
ganization  can  be  prioritized  for  the  evaluation.  Essentially,  the  high- 
est-risk  areas  can  be  examined  first  or  more  frequently  [GAO  99]. 


Next  Steps  (RA.9) 

Requirements  The  evaluation  must  include  an  activity  where  organizational  per¬ 

sonnel  identify  the  next  steps  required  to  implement  security  strate¬ 
gies  and  plans.  This  activity  often  requires  active  sponsorship  and 
participation  from  the  organization’s  senior  managers.  Next  steps 
typically  include  the  following  information: 

•  what  the  organization  will  do  to  build  on  the  results  of  the 
evaluation 

•  who  will  be  involved  in  implementing  security  strategies  and 
plans 

•  plans  for  future  activities  to  evaluate  information  security  risks 

Importance  Identifying  the  next  steps  that  people  in  the  organization  must  take  to 

implement  the  protection  strategy  and  the  mitigation  plans  is  essen¬ 
tial  for  security  improvement.  The  people  in  the  organization  need  to 
build  upon  the  results  of  the  evaluation.  Getting  senior  management 
sponsorship  is  the  first  critical  step  toward  making  this  happen. 
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Focus  on  Risk  (RA.10) 

Requirements  The  evaluation  must  focus  on  assessing  an  organization's  informa¬ 

tion  security  risks  by  examining  the  interrelationships  among  assets, 
threats  to  the  assets,  and  vulnerabilities  (including  both  organiza¬ 
tional  and  technological  weaknesses). 


Importance  This  attribute  is  important  because  it  requires  the  organization’s  per¬ 

sonnel  to  focus  on  security  issues  and  their  effect  on  the  organiza¬ 
tion’s  business  objectives  and  mission.  Personnel  must  look  beyond 
the  organizational  and  technological  weaknesses  that  are  present  in 
the  organization  and  examine  how  those  weaknesses  are  related  to 
the  organization’s  critical  assets  and  the  threats  to  those  assets,  thus 
establishing  the  risk  to  those  assets. 


Focused  Activities  (RA.11) 

Requirements  The  evaluation  process  must  include  guidelines  for  focusing  evalua¬ 

tion  activities.  Examples  include 

•  workshops  that  efficiently  elicit  security-related  information 
from  an  organization’s  staff  members 

•  analysis  activities  that  use  asset  information  to  focus  threat  and 
risk  identification  activities 

•  analysis  activities  that  use  asset  and  threat  information  to  set  the 
scope  of  the  infrastructure  vulnerability  evaluation 

•  planning  activities  that  establish  risk  priorities  using  risk  meas¬ 
ures  (impact,  probability) 

Importance  Focusing  each  activity  on  the  most  critical  information  security  is¬ 

sues  is  important  for  ensuring  that  the  organization  is  applying  its 
resources  efficiently.  If  too  much  information  is  gathered,  it  is  often 
difficult  to  analyze  the  information.  Focusing  on  the  most  important 
information  reduces  the  size  of  the  evaluation,  making  it  easier  to 
perform  the  activities  while  still  collecting  the  most  meaningful  data 
and  producing  the  most  meaningful  results. 


30 


CMU/SEI-2001-TR-016 


Organizational  and  Technological  Issues  (RA.12) 

Requirements  The  evaluation  process  must  examine  both  organizational  and  tech¬ 

nological  issues.  Information  security  risk  evaluations  typically  in¬ 
clude  the  following  practice-  and  vulnerability-related  information: 

•  current  security  practices  used  by  staff  members 

•  missing  or  inadequate  security  practices  (also  called  organiza¬ 
tional  vulnerabilities) 

•  technological  weaknesses  present  in  key  information  technology 
systems  and  components 

Importance  Because  security  has  both  organizational  and  technological  compo¬ 

nents,  it  is  important  that  an  evaluation  surface  both  organizational 
and  technological  issues.  The  analysis  team  analyzes  both  types  of 
issues  in  relation  to  the  mission  and  business  objectives  of  the  or¬ 
ganization  when  creating  the  organization’s  protection  strategy  and 
risk  mitigation  plans.  By  doing  this,  the  team  is  able  to  address  secu¬ 
rity  by  creating  a  global  picture  of  the  information  security  risks  with 
which  the  organization  must  deal. 
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Business  and  Information  Technology  Participation  (RA.13) 

Requirements  The  evaluation  process  must  include  participants  from  both  the  busi¬ 

ness  units  and  the  information  technology  department.  This  includes 
the  establishment  of  an  interdisciplinary  analysis  team.  (See  Attribute 
RA.l.)  It  also  includes  the  need  for  participants  from  key  areas  (busi¬ 
ness  units)  of  the  organization  to  contribute  their  perspectives  about 
security-related  issues  during  knowledge  elicitation  activities.  Note 
that  participants  must  include  representatives  from  multiple 
organizational  levels  (senior  management,  middle  management,  and 
staff). 


Importance  Incorporating  multiple  perspectives  is  essential  for  ensuring  that  a 

broad  range  of  risk  factors  is  considered.  Staff  members  who  work  in 
the  business  lines  of  an  organization  understand  the  relative  impor¬ 
tance  of  business  operations  and  the  systems  and  information  that 
support  these  operations.  In  general,  they  are  in  the  best  position  to 
understand  the  business  impact  of  disruption  or  abuse  to  business 
systems  and  operations  and  the  impact  of  potential  mitigation  ac¬ 
tions.  Information  technology  staff  members,  including  information 
security  experts,  understand  the  design  of  existing  systems  and  the 
impact  of  technology-related  vulnerabilities.  They  are  also  in  the  best 
position  to  evaluate  the  tradeoffs  of  mitigation  actions  when  evaluat¬ 
ing  their  effect  on  system  performance. 
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Senior  Management  Participation  (RA.14) 

Requirements  Senior  nnanagers  in  the  organization  must  have  defined  roles  during 

the  evaluation  process.  Typically,  an  organization’s  senior  managers 

•  demonstrate  active  sponsorship  of  the  evaluation 

•  participate  in  workshops  to  contribute  their  understanding  of 
security-related  issues  and  their  effect  on  business  processes 

•  review  and  approve  security  strategies  and  plans 

•  define  the  next  steps  required  to  implement  security  strategies 
and  plans 

Importance  This  is  the  single  most  important  success  factor  for  information  secu¬ 

rity  risk  evaluations.  Senior  management  participation  demonstrates 
strong  sponsorship  of  the  evaluation.  This  level  of  sponsorship  helps 
to  ensure  that 

•  staff  members  are  available  to  participate  in  the  evaluation 

•  staff  members  take  the  evaluation  seriously  and  are  willing  to 
participate 

•  the  findings  are  implemented  after  the  evaluation 

The  senior  managers’  active  participation  in  an  information  security 
risk  evaluation  is  also  important  to  the  success  of  the  initiative.  Sen¬ 
ior  managers  can  help  to  define  the  scope  of  the  assessment  and  can 
help  to  identify  participants.  If  senior  managers  support  the  evalua¬ 
tion,  people  in  the  organization  tend  to  participate  actively.  If  senior 
managers  do  not  support  the  evaluation,  then  staff  support  for  the 
evaluation  will  dissipate  quickly. 
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Collaborative  Approach  (RA.15) 

Requirements  Each  activity  of  the  evaluation  process  must  include  interaction  and 

collaboration  among  the  people  who  are  participating  in  that  activity. 
Collaboration  can  be  achieved  through  the  use  of  workshops  or  other 
interactive  methods. 


Importance  A  collaborative  approach  is  an  essential  attribute  of  information  secu¬ 

rity  risk  evaluations.  Because  security  is  interdisciplinary  in  nature, 
completing  the  evaluation  activities  requires  interdisciplinary  knowl¬ 
edge  and  skills.  Thus,  it  is  important  that  each  evaluation  activity 
require  all  participating  individuals  to  interact  and  collaborate,  ensur¬ 
ing  that  the  necessary  skills  and  knowledge  are  used  to  complete  that 
activity  satisfactorily. 

This  far,  we  have  focused  on  the  broad  concepts  (principles)  and  the  characteristics  of  the 
evaluation  (attributes).  Next,  we  complete  the  criteria  by  examining  the  required  outputs  of 
the  evaluation. 
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6  OCTAVE  Outputs 


The  OCTAVE  criteria  define  an  approach  for  evaluating  an  organization’s  information  secu¬ 
rity  risks.  Thus  far  in  this  document,  we  have  examined  the  principles  and  attributes  of  the 
approach.  Now,  we  will  explore  the  required  outputs  of  the  evaluation.  The  OCTAVE  outputs 
define  the  outcomes  that  an  analysis  team  must  achieve  during  the  evaluation.  We  organize 
them  according  to  data  category.  The  following  list  highlights  the  basic  types  of  data  pro¬ 
duced  by  information  security  risk  evaluations: 

•  organizational  data 

•  technological  data 

•  risk  analysis  and  mitigation  data 

Thus,  we  present  OCTAVE  as  a  three-phased  approach  for  information  security  risk  evalua¬ 
tions.  The  three  phases  illustrate  the  interdisciplinary  nature  of  information  security  by  em¬ 
phasizing  its  organizational  and  technological  aspects.  In  Section  6.1,  we  describe  each  phase 
of  OCTAVE.  The  phase  descriptions  provide  sufficient  context  to  enable  you  to  understand 
the  nature  of  the  outputs. 

In  Sections  6.2  through  6.4,  we  present  the  requirements  of  each  output  of  OCTAVE  by 
phase.  Note  that  each  attribute  is  numbered  for  easy  cross-referencing.  Outputs  are  defined 
using  the  following  information: 

•  requirements  -  the  essential  characteristics  of  the  output 

•  importance  -  why  the  output  is  important  to  the  evaluation  process 
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6.1  Evaluation  Phases 


The  organizational,  technological,  and  analysis  aspects  of  an  information  security  risk  evalua¬ 
tion  provides  a  conceptual  framework  for  describing  the  evaluation  and  its  outputs.  We  have 
structured  OCTAVE  using  this  conceptual  framework.  The  result  is  a  three-phased  approach, 
corresponding  to  the  major  aspects  of  information  security  risk  evaluations. 

The  following  are  the  three  phases  of  OCTAVE: 

•  Phase  1:  Build  Asset-Based  Threat  Profiles 

•  Phase  2:  Identify  Infrastructure  Vulnerabilities 

•  Phase  3:  Develop  Security  Strategy  and  Plans 

In  the  following  sections,  we  describe  each  OCTAVE  Phase. 

6.1.1  Phase  1:  Build  Asset-Based  Threat  Profiles 

In  today’s  business  environment,  the  computing  infrastructure  is  distributed  across  organiza¬ 
tions.  In  addition,  many  business  processes  are  distributed,  with  staff  members  performing 
specialized  job  functions.  Thus,  all  staff  members  play  a  role  in  information  security.  Each 
person  has  unique  knowledge  of  what  information  is  important  to  completing  his  or  her  job 
tasks.  Each  person  also  has  a  unique  perspective  about  which  security  practices  are  currently 
being  used  to  protect  the  organization’s  information-related  assets  as  well  as  which  security 
practices  are  missing  or  inadequate.  In  Phase  I,  the  staff  members  from  across  an  organiza¬ 
tion  have  the  opportunity  to  contribute  what  they  know  about  the  organization’s  information 
security  issues  through  a  series  of  knowledge  elicitation  workshops. 

Phase  1  is  an  organizational  evaluation  that  includes  knowledge  elicitation,  data  consolida¬ 
tion,  and  analysis  activities.  In  the  knowledge  elicitation  activities,  staff  members  from  across 
the  organization  contribute  their  perspectives  about 

•  what  is  important  to  the  organization  (information-related  assets) 

•  what  is  currently  being  done  to  protect  those  assets  (security  practices) 

•  missing  or  inadequate  security  practices  (organizational  vulnerabilities) 

The  knowledge  elicitation  activities  require  representative  groups  of  staff  members  from 
across  the  organization  to  participate,  including  people  from  both  the  business  and  informa¬ 
tion  technology  areas  of  the  organization.  In  addition,  multiple  organizational  levels  (senior 
management,  operational  area  management,  staff)  must  be  represented.  The  analysis  team 
members  facilitate  the  knowledge  elicitation  activities,  ensuring  that  all  activities  are  com¬ 
pleted  satisfactorily. 
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In  the  data  consolidation  and  analysis  activities,  the  analysis  team 

•  groups  information  from  the  knowledge  elicitation  workshops 

•  selects  the  assets  that  are  most  important  to  the  organization  (critical  assets) 

•  describes  security  requirements  for  the  critical  assets 

•  identifies  threats  to  the  critical  assets 

In  all  Phase  1  activities,  the  analysis  team  can  include  selected  personnel  to  augment  its  skills 
when  necessary. 

The  required  outputs  for  Phase  1  are 


ROl.l 

Critical  Assets 

R01.2 

Security  Requirements  for  Critical  Assets 

R01.3 

Threats  to  Critical  Assets 

R01.4 

Current  Security  Practices 

R01.5 

Current  Organizational  Vulnerabilities 

The  knowledge  elicitation  workshops  are  important  for  identifying  what  is  really  happening 
in  the  organization  with  respect  to  information  security.  The  data  consolidation  and  analysis 
activities  are  important  because  they  capture  the  organizational  view  of  information  security. 
The  outputs  of  the  data  consolidation  and  analysis  activities  are  important  because  those  out¬ 
puts  are  used  to 

•  focus  subsequent  evaluation  activities 

•  create  the  basis  for  the  organization’s  protection  strategy  and  risk  mitigation  plans  that 
are  created  during  Phase  3 

6.1.2  Phase  2:  Identify  Infrastructure  Vulnerabilities 

Phase  2  is  an  evaluation  of  the  information  infrastructure.  Phase  2  includes  data  gathering  and 
analysis  activities.  The  analysis  team 

•  scopes  the  examination  of  the  computing  infrastructure  using  the  critical  assets  and 
threats  to  those  assets 

•  identifies  key  information  technology  systems  and  components  that  are  related  to  each 
critical  asset 

•  runs  vulnerability  evaluation  tools  against  the  key  components 

•  analyzes  the  resulting  data  to  identify  weaknesses  (technology  vulnerabilities)  that  can 
lead  to  unauthorized  action  against  critical  assets 
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The  analysis  team  members  are  the  key  participants  in  Phase  2  activities.  In  addition,  key 
information  technology  staff  members  can  be  included  if  the  analysis  team  needs  to  enhance 
its  knowledge  and  skills  in  information  technology.  These  additional  people  can  be  a  part  of 
the  organization  or  can  be  from  an  external  organization.  It  is  important  to  ensure  that  the 
individuals  leading  this  activity  have  an  in-depth  understanding  of  information  technology 
and  computer  security  issues. 

The  required  outputs  for  Phase  2  are 

•  R02.I  Key  Components 

•  R02.2  Current  Technology  Vulnerabilities 

Phase  2  captures  the  technological  view  of  information  security,  resulting  in  an  understanding 
of  the  technology  vulnerabilities  that  are  present  in  and  apply  to  network  services,  architec¬ 
ture,  operating  systems,  and  applications.  Phase  2  is  important  because 

•  the  outputs  of  Phase  1  are  examined  in  relation  to  the  computing  infrastructure 

•  the  outputs  of  Phase  2  document  the  present  state  of  the  computing  infrastructure  with 
respect  to  technological  weaknesses  that  could  be  exploited  by  human  threat  actors 

6.1.3  Phase  3:  Develop  Security  Strategy  and  Plans 

Phase  3  includes  risk  analysis  and  risk  mitigation  activities.  During  risk  analysis,  the  analysis 
team  identifies  and  analyzes  the  risks  to  the  organization’s  critical  assets.  Specifically,  the 
team 

•  gathers  data  used  to  measure  the  risks  to  critical  assets  (e.g.,  impact  descriptions  and 
probability  data) 

•  defines  the  risk  evaluation  criteria  for  risk  measures,  establishing  a  common  understand¬ 
ing  of  the  qualitative  measures  (high,  medium,  low)  of  impact 

•  evaluates  risks  against  the  evaluation  criteria 

During  risk  mitigation,  the  analysis  team  creates  a  protection  strategy  and  mitigation  plans 
based  upon  an  analysis  of  the  information  gathered.  Specifically,  the  team 

•  develops  a  protection  strategy  for  organizational  improvement  and  risk  mitigation  plans 
to  protect  the  organization’s  information-related  assets 

•  identifies  next  steps  that  will  be  taken  to  implement  the  protection  strategy  and  the  miti¬ 
gation  plans 

The  analysis  team  members  are  the  key  participants  in  Phase  2  activities.  If  appropriate,  the 
analysis  team  can  include  selected  personnel  to  augment  its  skills.  The  organization’s  senior 
managers  review  and  approve  the  protection  strategy  and  risk  mitigation  plans. 
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The  required  outputs  for  Phase  3  are 


R03.1 

Risks  to  Critical  Assets 

R03.2 

Risk  Measures 

R03.3 

Protection  Strategy 

R03.4 

Risk  Mitigation  Plans 

Phase  3  is  important  because  it  is  in  this  phase  that  the  analysis  team  makes  sense  of  its  in¬ 
formation  security  issues  and  develops  a  strategy  and  plans  for  improvement.  Phase  3  in¬ 
cludes  both  risk  analysis  and  risk  mitigation  activities.  The  risk  analysis  activities  of  Phase  3 

are  important  because  they 

•  put  information  security  threats  into  the  context  of  what  the  organization  is  trying  to 
achieve,  resulting  in  explicit  statements  of  risk  to  the  organization’s  critical  assets 

•  establish  the  criteria  for  measuring  risks  and  a  basis  for  setting  priorities  when  develop¬ 
ing  risk  mitigation  plans 

The  risk  mitigation  activities  of  Phase  3  are  important  because  they 

•  result  in  a  protection  strategy  designed  to  improve  the  organization’s  security  posture 

•  result  in  a  risk  mitigation  plan  for  each  critical  asset  designed  to  protect  that  critical  asset 

•  require  the  organization’s  senior  managers  to  review  the  protection  strategy  and  risk 
mitigation  plans  from  the  organizational  perspective,  developing  senior  management 
sponsorship  of  the  evaluation  results 

•  define  what  the  organization  will  do  to  implement  the  results  of  the  evaluation,  enabling 
ongoing  security  improvement 

In  the  next  three  sections,  we  examine  the  required  outputs  by  phase. 
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6.2  Phase  1  Outputs 


Critical  Assets  (R01.1) 

Requirements  The  evaluation  process  must  identify  which  assets  are  critical.  An 

asset  is  something  of  value  to  the  organization  [Hutt  95].  Critical  as¬ 
sets  are  those  that  are  believed  to  be  the  most  important  assets  to  the 
organization.  The  organization  will  suffer  a  large  adverse  impact  if 
the  security  requirements  of  these  assets  are  violated. 


Information  security  risk  evaluations  typically  include  the  following 

categories  of  assets:^ 

•  information  -  documented  (paper  or  electronic)  data  or  intellec¬ 
tual  property  used  to  meet  the  mission  of  the  organization 

•  systems  ~  information  systems  that  process  and  store  informa¬ 
tion.  Systems  are  a  combination  of  information,  software,  and 
hardware  assets.  Any  host,  client,  or  server  can  be  considered  to 
be  a  system. 

•  software  -  software  applications  and  services  (operating  systems, 
database  applications,  networking  software,  office  applications, 
custom  applications,  etc.) 

•  hardware  -  information  technology  physical  devices  (worksta¬ 
tions,  servers,  etc.) 

•  people  -  the  people  in  the  organization,  including  their  skills, 
training,  knowledge,  and  experience 


Importance  The  organization’s  critical  assets  are  used  to  focus  all  future  evalua¬ 

tion  activities. 


This  list  was  created  using  information  in  these  references:  [Files  89],  [BSI  95],  [Hutt  95],  and 
[Caelli91]. 
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Security  Requirements  for  Critical  Assets  (R01.2) 

Requirements  Security  requirements  outline  the  important  qualities  of  an  asset,  and 

they  must  be  identified  for  each  critical  asset.  The  following  are  se¬ 
curity  requirements  that  are  typically  considered  during  an  evalua¬ 
tion: 

•  confidentiality  -  the  need  to  keep  proprietary,  sensitive,  or  per¬ 
sonal  information  private  and  inaccessible  to  anyone  who  is  not 
authorized  to  see  it 

•  integrity  -  the  authenticity,  accuracy,  and  completeness  of  an 
asset 

•  availability  -  when  or  how  often  an  asset  must  be  present  or 
ready  for  use 

Importance  Security  requirements  provide  a  basis  for  risk  mitigation  plans  that 

are  developed  during  Phase  3. 
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Threats  to  Critical  Assets  (R01.3) 

Requirements  The  evaluation  process  must  include  a  structured  way  of  recording 

threats.  A  threat  is  an  indication  of  a  potential  undesirable  event 
[NSTISSC  98].  It  refers  to  a  situation  where  a  person  could  do  some¬ 
thing  undesirable  or  where  a  system  malfunction  or  natural  occur¬ 
rence  could  cause  an  undesirable  outcome.  Threats  typically  include 
the  following  types  of  components: 

•  asset  -  something  of  value  to  the  organization 

•  actor  -  who  or  what  may  violate  the  security  requirements  (con¬ 
fidentiality,  integrity,  availability)  of  an  asset 

•  motive  -  determination  of  whether  the  actor’s  intentions  are 
deliberate  or  accidental  (applies  only  to  human  actors) 

•  access  -  how  the  asset  will  be  accessed  by  the  actor,  i.e.,  network 
access  and  physical  access  (applies  only  to  human  actors) 

•  outcome  -  the  immediate  outcome  (disclosure,  modification, 
destruction,  loss,  interruption)  of  violating  the  security  require¬ 
ments  of  an  asset 

Importance  Understanding  the  threats  to  critical  assets  helps  to  form  the  basis  for 

examining  the  information  infrastructure  for  technology  vulnerabili¬ 
ties  during  Phase  2  and  for  identifying  and  analyzing  risks  during 
Phase  3. 
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Current  Security  Practices  (R01.4) 

Requirements  The  evaluation  must  identify  security  practices  currently  being  used 

by  the  organization.  Security  practices  are  those  actions  presently 
used  by  the  organization  to  initiate,  implement,  and  maintain  its  in¬ 
ternal  security  [BSI 95].  Security  practices  are  used  to  protect  an  or¬ 
ganization’s  information-related  assets. 


Importance  Identifying  which  security  practices  are  currently  being  used  by  the 

organization  helps  staff  members  understand  what  they  are  doing 
well  and  which  security  practices  they  need  to  maintain.  The  current 
security  practices  used  by  the  organization  form  the  basis  upon 
which  a  protection  strategy  for  the  organization  can  be  built. 


Current  Organizational  Vulnerabilities  (R01.5) 

Requirements  The  evaluation  must  identify  organizational  vulnerabilities  that  are 

present  in  the  organization.  Organizational  vulnerabilities  are  weak¬ 
nesses  in  organizational  policy  or  practice  that  can  result  in  unauthor¬ 
ized  actions  occurring.  They  are  indications  of  missing  or  inadequate 
security  practices. 


Importance  Identifying  which  organizational  vulnerabilities  are  currently  present 

in  the  organization  helps  staff  members  understand  which  security 
practices  they  need  to  improve.  Those  areas  of  improvement  can  be 
incorporated  into  an  organization’s  protection  strategy  and  risk  miti¬ 
gation  plans. 
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6.3  Phase  2  Outputs 


Key  Components  (R02.1) 

Requirements  The  evaluation  must  identity  key  infrastructure  components  to  exam¬ 

ine  for  technology  vulnerabilities.  Key  components  are  devices  that 
are  important  in  processing,  storing,  or  transmitting  critical  informa¬ 
tion.  They  represent  assets  related  to  critical  assets.  Components 
from  the  following  classes  are  typically  considered  during  an  infor¬ 
mation  security  risk  evaluation; 

•  servers  -  hosts  within  your  information  technology  infrastructure 
that  provide  information  technology  services  to  your  organiza¬ 
tion 

•  networking  components  —  devices  important  to  your  organiza¬ 
tion’s  networks.  Routers,  switches,  and  modems  are  all  examples 
of  networking  components. 

•  security  components  -  devices  that  have  security  as  their  primary 
function  (e.g..  a  firewall) 

•  desktop  workstations  —  hosts  on  your  networks  that  staff  mem¬ 
bers  use  to  conduct  business 

•  home  computers  -  home  personal  computers  (PCs)  that  staff 
members  use  to  access  information  remotely  via  your  organiza¬ 
tion’s  networks 

•  laptops  -  portable  PCs  that  staff  members  use  to  access  informa¬ 
tion  remotely  via  your  organization’s  networks 

•  storage  devices  -  devices  where  information  is  stored,  often  for 
backup  purposes 

•  wireless  components  —  devices,  such  as  cell  phones  and  wireless 
access  points,  that  staff  members  may  use  to  access  information 
(e.g.,  email) 

•  others  -  any  other  type  of  device  that  could  be  part  of  your  threat 
scenarios  but  that  does  not  fall  into  the  above  classes 


Importance  Key  components  are  selected  infrastructure  components  that  are 

evaluated  for  technology  vulnerabilities.  These  components  set  the 
scope  of  the  technology  vulnerability  evaluation. 
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Current  Technology  Vulnerabilities  (R02.2) 

Requirements  The  information  security  risk  evaluation  must  identify  technology 

vulnerabilities  in  the  computing  infrastructure.  Technology  vulner¬ 
abilities  are  weaknesses  in  systems  that  can  directly  lead  to  unauthor¬ 
ized  action  [NSTISSC  98].  Technology  vulnerabilities  are  present  in 
and  apply  to  network  services,  architecture,  operating  systems,  and 
applications.  Types  of  technology  vulnerabilities  include  design,  im¬ 
plementation,  and  configuration  vulnerabilities. 


Importance  Technology  vulnerabilities  are  important  because  they  are  specific 

weaknesses  in  an  organization’s  computing  infrastructure  that  could 
be  exploited  by  human  threat  actors.  Thus,  identifying  technology 
vulnerabilities  helps  to  capture  the  present  state  of  the  computing 
infrastructure.  In  addition,  patterns  of  technology  vulnerabilities  can 
indicate  problems  with  the  current  security  practices  in  your  organi¬ 
zation  (organizational  vulnerabilities). 
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6.4  Phase  3  Outputs 


Risks  to  Critical  Assets  (R03.1) 

Requirements  The  evaluation  process  must  include  a  structured  way  of  recording 

risks.  Risk  is  the  possibility  of  suffering  harm  or  loss.  It  is  the  poten¬ 
tial  for  realizing  unwanted  negative  consequences  of  an  event  [Rowe 
88].  Risk  refers  to  a  situation  where  a  person  could  do  something 
undesirable  or  where  a  system  malfunction  or  natural  occurrence 
could  cause  an  undesirable  outcome,  resulting  in  a  negative  impact 
or  consequence.  Essentially,  a  risk  includes  the  threat  to  an  asset  plus 
the  resulting  impact  on  the  organization.  Risks  typically  include  the 
following  types  of  components: 

•  asset  ~  something  of  value  to  the  organization 

•  actor  -  who  or  what  may  violate  the  security  requirements  (con¬ 
fidentiality,  integrity,  availability)  of  an  asset 

•  motive  -  determination  of  whether  the  actor’s  intentions  are  de¬ 
liberate  or  accidental  (applies  only  to  human  actors) 

•  access  -  how  the  asset  will  be  accessed  by  the  actor,  i.e.,  network 
access  and  physical  access  (applies  only  to  human  actors) 

•  outcome  -  the  immediate  outcome  (disclosure,  modification, 
destruction,  loss,  interruption)  of  violating  the  security  require¬ 
ments  of  an  asset 

•  impact  -  a  description  of  the  effect  of  a  threat  on  an  organiza¬ 
tion’s  mission  and  business  objectives 

Importance  Identifying  the  risks  to  critical  assets  captures  the  effect  of  threats  on 

the  organization’s  mission  and  business  objectives.  Understanding 
the  risks  to  critical  assets  is  important  because  it  focuses  on  the  effect 
of  threats  on  the  organization  by  putting  threats  into  the  context  of 
what  the  organization  is  trying  to  achieve.  It  forms  the  basis  for  set¬ 
ting  priorities  during  Phase  3. 
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Risk  Measures  (R03.2) 

Requirements  The  evaluation  process  must  establish  a  means  to  measure  the  level 

of  risk  to  each  critical  asset.  Impact  value  is  an  essential  risk  meas¬ 
ure.  It  is  a  measurement  of  the  ultimate  effect  on  an  organization’s 
mission  and  business  objectives  resulting  from  a  threat  to  a  critical 
asset.  Probability  is  an  optional  risk  measure  in  the  risk  analysis.  It  is 
a  measurement  of  the  likelihood  of  occurrence  of  a  threat.  Impact 
value  and  probability  (if  used)  are  typically  measured  using  a  qualita¬ 
tive  scale  of  high,  medium,  and  low.  The  qualitative  scale  needs  to  be 
established  based  on  what  is  important  to  an  organization.  Quantita¬ 
tive  measurements  of  impact  value  and  probability  can  be  used  pro¬ 
vided  that  sufficient  data  to  support  quantitative  measurement  or  es¬ 
timation  exist. 


Importance  Understanding  impact  measures  for  risks  is  important  because  these 

measures  are  used  when  setting  mitigation  priorities  during  Phase  3. 
Probability  measures,  if  used,  are  important  in  refining  mitigation 
priorities. 


Protection  Strategy  (R03.3) 

Requirements  A  protection  strategy  must  be  an  output  of  the  evaluation  process.  An 

organization’s  protection  strategy  defines  its  direction  with  respect  to 
efforts  to  improve  information  security.  It  includes  approaches  for 
enabling,  implementing,  and  maintaining  security  practices  in  an  or¬ 
ganization.  A  protection  strategy  tends  to  incorporate  long-term  or¬ 
ganization-wide  initiatives  and  is  structured  using  the  practice  areas 
defined  in  the  catalog  of  practices.  (See  Attribute  RA.3.) 


Importance  Creating  a  protection  strategy  is  important  because  it  charts  a  course 

for  organizational  improvement  with  respect  to  information  security 
activities. 
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Risk  Mitigation  Plans  (R03.4) 

Requirements  Risk  mitigation  plans  to  protect  critical  assets  must  be  an  output  of 

the  evaluation  process.  Risk  mitigation  plans  for  critical  assets  define 
the  mitigation  actions  intended  to  reduce  the  risks  to  the  organiza¬ 
tion’s  critical  assets.  During  the  development  of  these  plans,  the 
analysis  team  has  considered  organizational  resources  and  con¬ 
straints.  Risk  mitigation  plans  tend  to  incorporate  actions,  or  coun¬ 
termeasures,  designed  to  counter  the  threats  to  the  assets.  The  actions 
are  based  on  the  practices  contained  in  the  catalog  of  practices.  (See 
Attribute  RA.3.) 


Importance 


Creating  risk  mitigation  plans  is  important  because  they  set  the  ac¬ 
tions  required  to  protect  the  organization's  critical  assets. 
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7  Summary 


OCTAVE  is  an  approach  for  information  security  risk  evaluations  that  is  comprehensive,  sys¬ 
tematic,  context  driven,  and  self  directed.  It  enables  an  organization  to  sort  through  both  or¬ 
ganizational  and  technological  issues  to  understand  and  address  its  information  security  risks. 
It  provides  a  snapshot  in  time,  or  a  baseline,  that  can  be  used  to  focus  mitigation  and  im¬ 
provement  activities.  Thus,  OCTAVE  can  be  viewed  as  a  tool  that  facilitates  information  se¬ 
curity  improvement. 


An  interdisciplinary  team,  called  the  analysis  team,  leads  the  evaluation  activities  and  is  re¬ 
sponsible  for  making  decisions  about  the  organization’s  efforts  to  improve  information  secu¬ 
rity.  OCTAVE  requires  the  team  to  consider  the  relationships  among  critical  assets,  the  threats 
to  those  assets,  and  vulnerabilities  (both  organizational  and  technological)  that  can  expose 
assets  to  threats.  It  requires  the  analysis  team  to  evaluate  risks  in  an  operational  context.  At 
the  conclusion  of  the  evaluation,  the  team  creates  a  protection  strategy  for  organizational  im¬ 
provement  and  risk  mitigation  plans  to  reduce  the  risk  to  the  organization’s  critical  assets. 
Thus,  the  process  incorporates  both  strategic  and  tactical  views  of  risk. 

The  essential  elements  of  OCTAVE  are  embodied  in  a  set  of  criteria.  There  can  be  many 
methods  consistent  with  these  criteria,  but  there  is  only  one  set  of  OCTAVE  criteria.  These 
criteria  define  an  approach  for  evaluating  an  organization’s  information  security  risk  using  a 
set  of  principles,  attributes,  and  outputs.  The  OCTAVE  principles  are  the  fundamental  con¬ 
cepts  that  drive  the  nature  of  the  evaluation  and  define  the  philosophy  that  shapes  the  evalua¬ 
tion  process.  Attributes  are  the  distinctive  characteristics  of  the  evaluation  and  are  derived 
from  the  principles.  They  define  what  is  necessary  to  make  the  evaluation  a  success  from 
both  the  process  and  organizational  perspectives.  Finally,  the  outputs  define  the  outcomes 
that  an  analysis  team  must  achieve  during  the  evaluation.  By  implementing  a  risk  evaluation 
practice  based  on  the  OCTAVE  criteria,  an  organization  can  start  to  improve  its  overall  secu¬ 
rity  posture. 
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Appendix  A:  A  Set  of  Activities  Consistent 

with  the  OCTAVE  Criteria 


In  this  appendix,  we  present  a  set  of  requirements  for  activities  that  are  consistent  with  the 
OCTAVE  criteria.  These  are  the  requirements  that  we  used  when  we  developed  the  OCTAVE 
Method  [Aiberts  01].  We  recognize  that  there  is  more  than  one  set  of  activities  that  can  pro¬ 
duce  the  outputs  of  OCTAVE.  For  this  reason,  we  do  not  include  this  set  of  activities  as  part 
of  the  OCTAVE  criteria. 


Activities  are  defined  here  as  the  operations  performed  during  an  information  security  risk 
evaluation.  Table  3  illustrates  16  activities  that  can  be  used  to  produce  the  OCTAVE  outputs. 
We  present  the  activities  according  to  the  phases  defined  in  Section  6  of  this  document. 


Table  3:  OCTAVE  Activities  by  Phase 


OCTAVE  Activities 

Phase  1  Activities  (PI) 

Phase  2  Activities  (P2) 

Phase  3  Activities  (P3) 

Pl.l  Identify  Assets 

P 1 .2  Identify  Current  Security 

P2. 1  Select  Infrastructure  Compo¬ 
nents  to  Evaluate 

P3. 1  Identify  Risks  to  Critical  As¬ 
sets 

Practices 

P2.2  Run  Vulnerability  Evaluation 

P3.2  Create  Risk  Evaluation  Criteria 

PI. 3  Identify  Current  Organiza¬ 
tional  Vulnerabilities 

P 1 .4  Identify  Critical  Assets 

P 1 .5  Describe  Security  Require¬ 
ments  for  Critical  Assets 

P i  .6  Create  Threat  Profiles  for 
Critical  Assets 

Tools 

P2.3  Review  Vulnerabilities  and 
Summarize  Results 

P3.3  Evaluate  Risks  to  Critical  As¬ 
sets 

P3.4  Create  Protection  Strategy 

P3.5  Create  Risk  Mitigation  Plans 

P3.6  Review  Protection  Strategy 
and  Risk  Mitigation  Plans  with 
Management 

P3.7  Identify  Next  Steps 
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Table  4  illustrates  the  relationships  between  the  attributes  and  activities  of  OCTAVE.  You 
will  notice  that  the  diagram  for  each  activity  contains  coded  inputs  and  outputs.  The  follow¬ 
ing  list  indicates  the  numbering  scheme  throughout  this  appendix: 

•  I  -  indicates  an  input 

•  O  -  indicates  an  output 

•  PX.Y  -  indicates  Activity  Y  in  Phase  X 

•  _Z  -  indicates  a  sequence  number  for  an  input  or  output 

For  example,  IP2.1_1  indicates  that  this  is  the  first  input  of  Activity  P2.1,  while  OP3.3_3  in¬ 
dicates  that  this  is  the  third  output  of  Activity  P3.3.  Each  input  and  output  is  explained  in 
Section  A.4,  Data  Dictionary,  using  the  numbered  codes  as  a  key. 


In  this  appendix,  we  define  each  activity  using  the  following  information: 

•  activity  description  -  the  essential  elements  of  the  activity,  including  the  goal  of  the 
activity  and  the  questions  that  are  answered  by  performing  the  activity 

•  participants  -  who  is  essential  to  the  completion  of  the  activity 

•  diagram  ~  a  graphic  depiction  of  the  inputs  and  outputs  of  the  process 

•  importance  ~  why  the  activity  is  important  to  the  evaluation  process 
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Table  4:  Mapping  OCTAVE  Attributes  to  Activities 


R.15  Collaborative  Approach 


A.1  Phase  1  (Build  Asset-Based  Threat  Profiles)  Ac¬ 
tivities 

Phase  1  of  OCTAVE  is  entitled  Build  Asset-Based  Threat  Profiles.  It  is  an  organizational 
evaluation.  Phase  1  focuses  on  the  people  in  the  organization  and  requires  staff  members 
throughout  the  organization  to  participate  by  contributing  their  unique  perspectives  about  the 
following: 

•  the  information-related  assets  that  they  use  in  their  jobs 

•  the  current  security  practices  that  are  used  by  the  organization 

•  which  organizational  vulnerabilities  are  present  in  the  organization 

The  analysis  team  consolidates  the  information,  creating  an  organization-wide  view  of  infor¬ 
mation-related  assets,  current  security  practices,  and  current  organizational  vulnerabilities. 
The  team  then 

•  selects  the  assets  that  are  most  important  to  meeting  the  mission  and  business  objectives 
of  the  organization  (the  critical  assets) 

•  creates  a  set  of  security  requirements  for  each  critical  asset 

•  creates  a  unique  threat  profile  for  each  critical  asset  that  describes  the  range  of  threats 
that  applies  to  each  critical  asset 

Phase  1  is  composed  of  the  following  six  activities: 

PIT  Identify  Assets 

PI. 2  Identify  Current  Security  Practices 

PI. 3  Identify  Current  Organizational  Vulnerabilities 

PI .4  Identify  Critical  Assets 

PI. 5  Describe  Security  Requirements  for  Critical  Assets 

P1.6  Create  Threat  Profiles  for  Critical  Assets 
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P1 .1  Identify  Assets 


Activity  Description 


Participants 


The  goal  of  Activity  Pl.l  is  to  create  an  organization-wide  listing  of 
information-related  assets.  The  following  key  questions  must  be  an¬ 
swered  during  this  activity.  The  questions  focus  on  identifying  which 
assets  are  important  to  meeting  the  mission  and  business  objectives 
of  the  organization. 


_ Key  Questions  for  Pl.l:  Identify  Assets 

•  What  are  the  organization’s  important  assets? 

•  Are  there  any  other  assets  that  the  organization  is  required  to 
protect  (e  g.,  by  law  or  regulation)? 

•  What  related  assets  are  important? 

•  Which  assets  are  the  most  important?  Why? 

During  Activity  Pl.l,  information-related  assets  that  are  important  to 
meeting  the  mission  and  business  objectives  of  the  organization  are 
identified.  People  from  different  areas  of  the  organization  (e.g.,  busi¬ 
ness  and  information  technology  areas)  and  from  multiple  organiza¬ 
tional  levels  (e.g.,  senior  management,  operational  area  management, 
and  staff)  contribute  their  unique  perspectives  about  which  informa¬ 
tion-related  assets  they  use  in  their  jobs.  The  analysis  team  consoli¬ 
dates  the  individual  perspectives,  creating  an  organization-wide  view 
of  information-related  assets.  It  is  important  to  solicit  the  multiple 
perspectives  about  assets.  People  from  different  parts  of  the  organi¬ 
zation  rely  on  different  assets  to  perform  their  tasks.  Before  a  global 
perspective  of  assets  can  be  created,  the  individual  perspectives  must 
be  identified. 


A  representative  group  of  staff  members  from  across  the  organization 
participates  in  this  activity.  This  group  includes  people  from  both  the 
business  and  information  technology  areas  of  the  organization.  In 
addition,  multiple  organizational  levels  (senior  management,  opera¬ 
tional  area  management,  staff)  must  be  represented.  The  analysis 
team  members  facilitate  the  activity,  ensuring  that  the  activity  is 
completed  satisfactorily. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
PIT:  Identify  Assets. 


PIT 

_ _ ^  Identify  Assets 

Inputs 

•  Current  knowledge  of 

organizational  staff  \ _ 


- ► 

Outputs 

•  Assets  (OPl.l_l) 


Importance  An  asset  is  something  of  value  to  the  organization.  Information- 

related  assets  typically  include  information,  systems,  software,  hard¬ 
ware,  and  people.  Information-related  assets  are  important  to  meeting 
the  mission  and  business  objectives  of  the  organization.  By  knowing 
which  of  these  assets  are  most  important  to  the  organization,  man¬ 
agement  can  use  its  limited  resources  to  focus  on  protecting  the  most 
important  information-related  assets. 


Notes  Activity  Pl.l  consists  of  two  distinct  components:  a  knowledge  elici¬ 

tation  component  and  a  consolidation  component.  The  knowledge 
elicitation  component  requires  staff  members  from  across  the  organi¬ 
zation  to  contribute  their  understanding  of  which  information-related 
assets  are  important  to  the  organization.  The  analysis  team  then  con¬ 
solidates  the  individual  perspectives,  creating  an  organization-wide 
view  of  information-related  assets. 


Activity  PI. 2,  Identify  Current  Security  Practices,  and  Activity  PI. 3, 
Identify  Current  Organizational  Vulnerabilities,  also  have  knowledge 
elicitation  components.  Note  that  Activities  Pl.l,  PI. 2,  and  PI. 3  can 
be  conducted  together  during  a  single  session. 

When  staff  members  from  across  the  organization  create  an  organiza¬ 
tion-wide  listing  of  information-related  assets,  they  can  also  be  asked 
to  identify  the  security  requirements  for  and  perceived  threats  to  their 
most  important  assets.  The  analysis  team  can  use  the  security  re¬ 
quirements  data  as  input  to  Activity  P1.5,  Describe  Security  Re¬ 
quirements  for  Critical  Assets.  The  team  can  use  the  perceived  threat 
data  as  input  to  Activity  PI. 6,  Create  Threat  Profiles  for  Critical  As¬ 
sets.  Collecting  security  requirements  and  perceived  threat  informa- 
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tion  can  be  very  useful  in  certain  instances.  For  example,  in  very 
large  organizations,  the  analysis  team  might  not  have  sufficient  in¬ 
sight  into  all  operational  areas  participating  in  the  evaluation.  To  gain 
more  insight  into  the  operational  areas,  the  analysis  team  might  find 
it  useful  to  elicit  the  security  requirements  and  perceived  threats  from 
staff  members  who  are  participating  in  the  evaluation. 

Because  people  from  different  areas  of  the  organization  (e.g.,  busi¬ 
ness  and  information  technology  areas)  and  from  multiple  organiza¬ 
tional  levels  (e.g.,  senior  management,  operational  area  management, 
and  staff)  contribute  their  unique  perspectives  during  this  activity,  it 
is  important  to  structure  the  knowledge  elicitation  component  of  the 
activity  carefully.  The  analysis  team  should  make  sure  that  open 
communication  is  encouraged.  For  example,  if  a  workshop  format  is 
being  used  to  elicit  information,  the  analysis  team  might  want  to  as¬ 
sign  people  to  workshops  according  to  organizational  level.  People 
tend  to  discuss  issues  more  openly  when  there  are  no  real  or  per¬ 
ceived  reporting  relationships  among  the  participants  in  the  work¬ 
shop. 
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P1.2 


Identify  Current  Security  Practices 


Activity  Description  The  goal  of  Activity  PI. 2  is  to  create  an  organization-wide  listing  of 
the  current  security  practices  used  by  the  organization.  The  following 
key  questions  must  be  answered  during  this  activity.  The  questions 
focus  on  what  people  in  the  organization  believe  they  are  doing  to 
protect  the  organization's  important  information-related  assets. 

Key  Questions  for  PL2:  Identify  Current  Security  Practices 

•  What  is  the  organization  currently  doing  well  with  respect  to 
protecting  its  important  information-related  assets? 

•  Are  there  specific  policies,  procedures,  and  practices  unique  to 
specific  assets?  What  are  they? 

•  Is  the  organization's  protection  strategy  effective?  Why?  Why 
not? 

When  people  are  answering  the  first  key  question,  they  must  con¬ 
sider  their  organization's  practices  in  relation  to  a  catalog  of  prac¬ 
tices.  (See  Attribute  RA.3,  Catalog  of  Practices,  of  the  OCTAVE  cri¬ 
teria.)  This  allows  people  to  evaluate  their  organization’s  security 
practices  against  a  known  and  accepted  measure  of  security  practice. 

During  Activity  PI. 2,  current  security  practices  used  by  the  organiza¬ 
tion  to  protect  its  information-related  assets  are  identified.  People 
from  different  areas  of  the  organization  (e.g.,  business  and  informa¬ 
tion  technology  areas)  and  from  multiple  organizational  levels  (e.g., 
senior  management,  operational  area  management,  and  staff)  con¬ 
tribute  their  unique  perspectives  about  which  security  practices  are 
used  by  the  organization.  The  analysis  team  consolidates  the  individ¬ 
ual  perspectives,  creating  an  organization-wide  view  of  current  secu¬ 
rity  practices.  It  is  important  to  solicit  the  multiple  perspectives  about 
current  security  practices  used  by  the  organization.  People  from  dif¬ 
ferent  parts  of  the  organization  often  have  different  opinions  about 
what  the  organization  is  currently  doing  to  protect  its  assets.  Before  a 
global  perspective  of  current  security  practices  can  be  created,  the 
individual  perspectives  must  be  identified. 
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Participants 


A  representative  group  of  staff  members  from  across  the  organization 
participates  in  this  activity.  This  group  includes  people  from  both  the 
business  and  information  technology  areas  of  the  organization.  In 
addition,  multiple  organizational  levels  (senior  management,  opera¬ 
tional  area  management,  staff)  must  be  represented.  The  analysis 
team  members  facilitate  the  activity,  ensuring  that  the  activity  is 
completed  satisfactorily. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

PL2:  Identify  Current  Security  Practices. 


Inputs 

•  Current  knowledge  of 
organizational  staff 

•  Organizational  data 
(IPl.2^1) 

•  Laws  and  regulations 
(IP1.2_2) 

•  Catalog  of  practices 
(IP1.2_3) 

•  Assets  (OPT  1_1) 


P1.2 

Identify  Current 
Security  Practices 


- ► 

Outputs 

•  Current  security 
practices  (OPi.2_l) 


Importance  Security  practices  are  actions  that  help  initiate,  implement,  and  main¬ 

tain  security  within  an  organization.  It  is  important  for  people  in  an 
organization  to  understand  which  security  practices  are  currently  be¬ 
ing  used  to  protect  the  organization’s  information-related  assets.  This 
helps  staff  members  understand  what  they  are  currently  doing  well 
and  which  security  practices  they  need  to  maintain.  The  current  secu¬ 
rity  practices  used  by  the  organization  also  form  the  basis  upon 
which  a  protection  strategy  for  the  organization  can  be  built. 


CMU/SEI-2001-TR-016 


61 


Notes 


Activity  PI. 2  consists  of  two  distinct  components:  a  knowledge  elici¬ 
tation  component  and  a  consolidation  component.  The  knowledge 
elicitation  component  requires  staff  members  from  across  the  organi¬ 
zation  to  contribute  their  understanding  of  the  current  security  prac¬ 
tices  used  by  the  organization.  The  analysis  team  then  consolidates 
the  individual  perspectives,  creating  an  organization-wide  view  of 
current  security  practices. 

This  activity  is  directly  related  to  Activity  PI. 3.  Identify  Current  Or¬ 
ganizational  Vulnerabilities,  where  staff  members  focus  on  the  organ¬ 
izational  vulnerabilities  present  in  the  organization  (the  flip  side  of 
security  practices).  Because  of  the  link  between  security  practices 
and  organizational  vulnerabilities.  Activities  PI. 2  and  PI. 3  are  usu¬ 
ally  performed  together.  Note  that  Activities  Pl.l,  PI. 2,  and  PI. 3  can 
be  conducted  together  during  a  single  knowledge  elicitation  session. 

Because  people  from  different  areas  of  the  organization  (e.g.,  busi¬ 
ness  and  information  technology  areas)  and  from  multiple  organiza¬ 
tional  levels  (e.g.,  senior  management,  operational  area  management, 
and  staff)  contribute  their  unique  perspectives  during  this  activity,  it 
is  important  to  structure  the  knowledge  elicitation  component  of  the 
activity  carefully.  The  analysis  team  should  make  sure  that  open 
communication  is  encouraged.  For  example,  if  a  workshop  format  is 
being  used  to  elicit  information,  the  analysis  team  might  want  to  as¬ 
sign  people  to  workshops  according  to  organizational  level.  People 
tend  to  discuss  issues  more  openly  when  there  are  no  real  or  per¬ 
ceived  reporting  relationships  among  the  participants  in  the  work¬ 
shop. 
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P1.3  Identify  Current  Organizational  Vulnerabilities 


Activity  Description  The  goal  of  Activity  PI. 3  is  to  create  an  organization-wide  listing  of 

the  current  organizational  vulnerabilities  present  in  the  organization. 
The  following  key  questions  must  be  answered  during  this  activity. 
The  questions  focus  on  what  people  in  the  organization  believe  they 
are  not  doing  well  to  protect  the  organization’s  important  informa¬ 
tion-related  assets. 


Key  Questions  for  P1.3:  Identify  Current  Organizational 

Vulnerabilities 

•  What  is  the  organization  currently  not  doing  well  with  respect  to 
protecting  its  important  information-related  assets? 

•  Is  the  organization’s  protection  strategy  effective?  Why?  Why 
not? 

When  people  are  answering  the  first  key  question,  they  must  con¬ 
sider  their  organization’s  practices  in  relation  to  a  catalog  of  prac¬ 
tices.  (See  Attribute  RA.3,  Catalog  of  Practices,  of  the  OCTAVE  cri¬ 
teria.)  This  allows  people  to  evaluate  their  organization’s  security 
practices  against  a  known  and  accepted  measure  of  security  practice. 

During  Activity  PI. 3,  current  organizational  vulnerabilities  that  are 
present  in  the  organization  are  identified.  People  from  different  areas 
of  the  organization  (e.g.,  business  and  information  technology  areas) 
and  from  multiple  organizational  levels  (e.g.,  senior  management, 
operational  area  management,  and  staff)  contribute  their  unique  per¬ 
spectives  about  which  organizational  vulnerabilities  are  present  in 
the  organization.  The  analysis  team  consolidates  the  individual  per¬ 
spectives,  creating  an  organization-wide  view  of  current  organiza¬ 
tional  vulnerabilities.  It  is  important  to  solicit  the  multiple  perspec¬ 
tives  about  current  organizational  vulnerabilities  present  in  the 
organization.  People  from  different  parts  of  the  organization  often 
have  different  opinions  about  issues  related  to  what  the  organization 
is  currently  doing  to  protect  its  assets.  Before  a  global  perspective  of 
organizational  vulnerabilities  can  be  created,  the  individual  perspec¬ 
tives  must  be  identified. 
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A  representative  group  of  staff  members  from  across  the  organization 
participates  in  this  activity.  This  group  includes  people  from  both  the 
business  and  information  technology  areas  of  the  organization.  In 
addition,  multiple  organizational  levels  (senior  management,  opera¬ 
tional  area  management,  staff)  must  be  represented.  The  analysis 
team  members  facilitate  the  activity,  ensuring  that  the  activity  is 
completed  satisfactorily. 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
PI. 3:  Identify  Current  Organizational  Vulnerabilities. 


> 

Inputs 

•  Current  knowledge  of 
organizational  staff 

•  Organizational  data 
(IP1.2_1) 

•  Laws  and  regulations 
(IP1.2_2) 

•  Catalog  of  practices 
(IP1.2_3) 

•  Assets  (OPT  1_1) 

Importance  An  organizational  vulnerability  is  a  weakness  in  organizational  pol¬ 

icy  or  practice  that  can  result  in  the  occurrence  of  unauthorized  ac¬ 
tions.  Organizational  vulnerabilities  are  indications  of  missing  or 
inadequate  security  practices.  It  is  important  for  people  in  an  organi¬ 
zation  to  understand  which  organizational  vulnerabilities  are  present 
in  the  organization.  This  helps  them  understand  where  they  need  to 
improve  with  respect  to  security  practices.  The  current  organizational 
vulnerabilities  indicate  areas  of  improvement  that  can  be  incorpo¬ 
rated  into  an  organization’s  protection  strategy  and  risk  mitigation 
plans. 


f  ^ 

P1.3 

Identify  Current  _ ^ 

Organizational 

Vulnerabilities  Outputs 

,  •  Current  organizational 

^  vulnerabilities  (OPl  .3_1) 


Participants 


Diagram 
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Notes 


Activity  PI. 3  consists  of  two  distinct  components:  a  knowledge  elici¬ 
tation  component  and  a  consolidation  component.  The  knowledge 
elicitation  component  requires  staff  members  from  across  the  organi¬ 
zation  to  contribute  their  understanding  of  the  current  organizational 
vulnerabilities  present  in  the  organization.  The  analysis  team  then 
consolidates  the  individual  perspectives,  creating  an  organization- 
wide  view  of  current  organizational  vulnerabilities. 

This  activity  is  directly  related  to  Activity  PI. 2,  Identify  Current  Se¬ 
curity  Practices,  where  staff  members  focus  on  the  security  practices 
used  by  the  organization  (the  flip  side  of  organizational  vulnerabili¬ 
ties).  Because  of  the  link  between  security  practices  and  organiza¬ 
tional  vulnerabilities,  Activities  PI. 2  and  PI. 3  are  usually  performed 
together.  Note  that  Activities  Pl.l,  PI. 2,  and  PI. 3  can  be  conducted 
together  during  a  single  knowledge  elicitation  session. 

Because  people  from  different  areas  of  the  organization  (e.g.,  busi¬ 
ness  and  information  technology  areas)  and  from  multiple  organiza¬ 
tional  levels  (e.g,,  senior  management,  operational  area  management, 
and  staff)  contribute  their  unique  perspectives  during  this  activity,  it 
is  important  to  structure  the  knowledge  elicitation  component  of  the 
activity  carefully.  The  analysis  team  should  make  sure  that  open 
communication  is  encouraged.  For  example,  if  a  workshop  format  is 
being  used  to  elicit  information,  the  analysis  team  might  want  to  as¬ 
sign  people  to  workshops  according  to  organizational  level.  People 
tend  to  discuss  issues  more  openly  when  there  are  no  real  or  per¬ 
ceived  reporting  relationships  among  the  participants  in  the  work¬ 
shop. 
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P1 .4  Identify  Critical  Assets 


Activity  Description 


Participants 


The  goal  of  Activity  PI. 4  is  to  select  those  assets  that  are  the  most 
important  to  the  organization.  The  following  key  questions  must  be 
answered  during  this  activity.  The  questions  focus  on  violations  of 
the  assets’  security  requirements.  As  such,  each  question  is  framed 
around  a  specific  threat  outcome. 

Key  Questions  for  PL4:  Identify  Critical  Assets 

•  Which  assets  will  cause  a  large  adverse  impact  on  the  organiza¬ 
tion  if  they  are  disclosed  to  unauthorized  people? 

•  Which  assets  will  cause  a  large  adverse  impact  on  the  organiza¬ 
tion  if  they  are  modified  without  authorization? 

•  Which  assets  will  cause  a  large  adverse  impact  on  the  organiza¬ 
tion  if  they  are  lost  or  destroyed? 

•  Which  assets  will  cause  a  large  adverse  impact  on  the  organiza¬ 
tion  if  access  to  them  is  interrupted? 

During  Activity  PI. 4,  the  critical  assets  of  the  organization  are  se¬ 
lected.  The  analysis  team  first  reviews  all  information-related  assets 
that  have  been  identified  by  participants  from  the  organization.  The 
team  then  selects  those  assets  that  are  most  important  to  meeting  the 
mission  and  business  objectives  of  the  organization.  The  number  of 
critical  assets  is  small  (often  no  more  than  five). 


The  analysis  team  members  are  the  key  participants  in  this  activity.  If 
appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
PI. 4:  Identify  Critical  Assets. 


- ► 

Outputs 

•  Critical  assets  (OP1.4_l) 

•  Assets  (OPl.l_l) 


Inputs 

•  Current  knowledge  of 
analysis  team 


P1.4 

Identify  Critical 
Assets 


Importance  Critical  assets  are  those  that  are  believed  to  be  the  most  important 

assets  to  the  organization.  The  organization  will  suffer  a  large  ad¬ 
verse  impact  if  the  security  requirements  of  these  assets  are  violated. 
The  critical  assets  are  used  to  focus  all  future  evaluation  activities. 


CMU/SEI-2001-TR-016 


67 


P1.5 


Describe  Security  Requirements  for  Critical  Assets 


Activity  Description 


Participants 


The  goal  of  Activity  PI. 5  is  to  describe  the  security  requirements  for 
each  critical  asset.  The  following  key  questions  must  be  answered 
during  this  activity.  The  questions  focus  on  the  important  qualities  of 
the  assets. 

Key  Questions  for  P1.5:  Describe  Security  Requirements  for 
Critical  Assets 

•  Is  the  critical  asset  proprietary  or  sensitive?  Does  it  contain  per¬ 
sonal  information?  Should  it  be  inaccessible  to  anyone  who  is 
not  authorized  to  see  it?  If  the  answer  to  any  of  these  questions  is 
yes,  what  is  the  specific  confidentiality  requirement? 

•  Are  authenticity,  accuracy,  and  completeness  important  for  the 
critical  asset?  If  yes,  what  is  the  specific  integrity  requirement? 

•  Is  accessibility  of  the  critical  asset  important?  If  yes,  what  is  the 
specific  availability  requirement? 

•  Are  there  any  other  security-related  requirements  that  are  impor¬ 
tant  to  the  critical  asset?  What  are  they? 

During  Activity  PI. 5,  the  security  requirements  for  the  critical  assets 
are  described  from  the  organizational  perspective.  The  analysis  team 
creates  a  set  of  security  requirements  for  each  critical  asset.  In  creat¬ 
ing  the  security  requirements  for  a  critical  asset,  the  analysis  team 
considers  the  confidentiality,  integrity,  and  availability  of  that  asset. 
The  team  also  considers  tradeoffs  among  the  security  requirements, 
identifying  which  requirement  is  ultimately  most  important  for  each 
critical  asset. 


The  analysis  team  members  are  the  key  participants  in  this  activity.  If 
appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
PI. 5:  Describe  Security  Requirements  for  Critical  Assets. 


r 


PI. 5 


Inputs 


Current  knowledge  of 
analysis  team 


Describe  Security 
Requirements  for 
Critical  Assets 


•  Critical  assets 
(OPI.4_l) 


- ► 

Outputs 

•  Security  requirements  for 
critical  assets  (OP1.5„l) 


Importance  Security  requirements  for  critical  assets  outline  the  qualities  of  the 

critical  assets  that  are  important  to  an  organization.  Security  re¬ 
quirements  also  provide  a  basis  for  developing  the  protection  strategy 
and  risk  mitigation  plans  during  Phase  3. 
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P1.6 


Create  Threat  Profiles  for  Critical  Assets 


Activity  Description 


Participants 


The  goal  of  Activity  PI  .6  is  to  identify  the  range  of  threats  that  can 
affect  each  critical  asset.  The  following  key  questions  must  be  an¬ 
swered  during  this  activity.  The  questions  focus  on  how  the  critical 
assets  are  threatened. 


Key  Questions  for  P1.6:  Create  Threat  Profiles  for  Critical 

Assets 

•  For  which  potential  threats  is  there  a  non-negligible  possibility  of 
a  threat  to  the  critical  asset? 

•  For  which  potential  threats  is  there  a  negligible  possibility  or  no 
possibility  of  a  threat  to  the  critical  asset? 

During  Activity  PI. 6.  threats  to  each  critical  asset  are  identified.  The 
analysis  team  examines  each  critical  asset  in  the  context  of  the  poten¬ 
tial  threats  in  the  generic  threat  profile.  The  team  then  decides  which 
of  the  threats  in  the  profile  applies  to  each  critical  asset,  creating  a 
unique  threat  profile  for  each  critical  asset.  The  generic  threat  profile 
provides  the  range  of  common  threat  scenarios  to  consider  when  de¬ 
veloping  a  threat  profile  for  a  critical  asset.  When  creating  a  threat 
profile  for  a  critical  asset,  the  analysis  team  also  considers  unique 
threats  that  might  not  be  in  the  generic  threat  profile. 


The  analysis  team  members  are  the  key  participants  in  this  activity.  If 
appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
PI. 6:  Create  Threat  Profiles  for  Critical  Assets. 


- ► 

Outputs 

•  Threat  profile  for  critical 
assets  (OP1.6_l) 

•  Generic  threat  profile 
(IP1.6_1) 

•  Critical  assets 
(OP1.4_l) 


Importance  Threats  to  critical  assets  are  potential  situations  that  can  adversely 

affect  an  organization’s  critical  assets.  The  threat  profiles  created 
during  this  activity  help  to  form  the  basis  for  examining  the  informa¬ 
tion  infrastructure  for  vulnerabilities  during  Phase  2  and  for  identify¬ 
ing  and  analyzing  risks  during  Phase  3. 


Inputs 

•  Current  knowledge  of 
analysis  team 


P1.6 

Create  Threat  Pro¬ 
files  for  Critical  As¬ 
sets 


Notes  In  some  cases,  perceived  threat  information  could  have  been  gathered 

during  Activity  Pl.l.  This  information  can  be  used  as  an  input  to  Ac¬ 
tivity  PI. 6. 
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A.2  Phase  2  (Identify  Infrastructure  Vulnerabilities) 
Activities 

Phase  2  of  OCTAVE  is  entitled  Identify  Infrastructure  Vulnerabilities.  It  is  a  technological 
evaluation  that  focuses  on  the  organization’s  computing  infrastructure.  During  Phase  2,  the 
analysis  team  and  key  information  technology  (IT)  staff  members 

•  select  specific  infrastructure  components  to  examine  for  technology  vulnerabilities 

•  select  an  approach  for  evaluating  each  infrastructure  component 

•  develop  a  summary  of  the  technology  vulnerabilities  affecting  each  critical  asset 

•  refine  the  threat  profile  for  each  critical  asset  based  upon  the  evaluation  of  that  asset’s 
key  infrastructure  components 

Phase  2  is  composed  of  the  following  three  activities: 

P2. 1  Select  Infrastructure  Components  to  Evaluate 

P2.2  Run  Vulnerability  Evaluation  Tools 

P2.3  Review  Vulnerabilities  and  Summarize  Results 

We  describe  each  activity  in  the  remainder  of  this  section. 
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P2.1  Select  Infrastructure  Components  to  Evaluate 


Activity  Description 


The  goals  of  Activity  P2.1  are  to  select  specific  infrastructure 
components  to  examine  for  technology  vulnerabilities  by  examining 
network  access  to  each  critical  asset  and  to  select  an  approach  for  the 
vulnerability  evaluation.  When  selecting  components  and  an 
approach,  the  analysis  team  must  balance  the  comprehensiveness  of 
the  evaluation  with  the  effort  required  to  evaluate  the  components. 
The  following  key  questions  must  be  answered  during  this  activity. 
The  questions  focus  on  identifying  typical  components  and  on 
selecting  approaches  for  evaluating  components. 

Key  Questions  for  P2.1:  Select  Infrastructure  Components  to 

Evaluate 

•  Which  specific  component(s)  will  be  evaluated  for  technology 
vulnerabilities? 

Is  the  infrastructure  component  typical  of  its  class? 

How  accessible  is  the  infrastructure  component?  Is  it 
“owned”  by  another  organization?  Is  it  a  home  machine? 

How  critical  is  the  infrastructure  component  to  business  op¬ 
erations?  Will  business  operations  be  interrupted  when  the 
component  is  evaluated? 

What  is  the  rationale  for  selecting  this  specific  compo- 
nent(s)? 

•  What  approach  will  be  used  to  evaluate  each  selected  compo¬ 
nent? 

Who  will  perform  the  evaluation? 

Which  vulnerability  evaluation  tool(s)  will  be  used? 

Will  special  permission  or  scheduling  be  required  to  evaluate 
the  component? 

During  Activity  P2.1,  specific  infrastructure  components  are  selected 
for  evaluation.  For  each  critical  asset,  the  analysis  team  and  key  IT 
staff  members  review  the  threats  for  human  actors  using  network 
access.  These  threats  affect  a  critical  asset  due  to  deliberate  exploita¬ 
tion  of  technology  vulnerabilities  or  accidental  actions  by  people. 
Based  on  the  specific  threats  of  this  type  to  the  critical  asset,  the  team 
determines  infrastructure  components  that  are  used  by  legitimate  us¬ 
ers  to  access  the  critical  asset.  They  also  identify  which  components 
threat  actors  could  use  to  access  the  critical  asset. 
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Participants 


For  organizations  with  large  computing  infrastructures,  an  optional 
first  step  is  to  identify  key  classes  of  infrastructure  components.  In¬ 
dividual  components  from  each  key  class  are  then  selected  for 
evaluation.  Then,  individual  components  from  each  key  class  are 
selected  for  evaluation,  making  the  infrastructure  vulnerability 
evaluation  a  more  manageable  activity.  The  following  questions 
could  be  answered  during  this  optional  step.  These  questions  focus 
on  components  that  are  part  of  or  related  to  the  critical  assets. 


Optional  Key  Questions  for  P2.1:  Select  Infrastructure 
Components  to  Evaluate  (Key  Classes  of  Components) 

•  Which  system(s)  is  most  closely  linked  to  the  critical  asset?  In 
which  system(s)  is  the  critical  asset  stored  and  processed? 

Which  types  of  components  are  part  of  the  system  of  inter¬ 
est?  Consider  servers,  networking  components,  security 
components,  desktop  workstations,  home  machines,  laptops, 
storage  devices,  wireless  components,  and  others. 

Which  types  of  components  are  related  to  the  system  of  in¬ 
terest?  From  which  types  of  hosts  can  the  system  of  interest 
be  legitimately  accessed?  Consider  desktop  machines,  home 
machines,  laptops,  cellular  phones,  handheld  devices,  and 
others. 

How  could  threat  actors  access  the  system(s)?  Via  the  Inter¬ 
net?  Via  the  internal  network?  Shared  external  networks? 
Wireless  devices?  Others? 

Which  types  of  components  could  a  threat  actor  use  to  access 
the  system  of  interest?  Which  could  serve  as  intermediate 
access  points?  Consider  physical  and  network  access  to  serv¬ 
ers,  networking  components,  security  components,  desktop 
workstations,  home  machines,  laptops,  storage  devices,  wire¬ 
less  components,  and  others. 


The  analysis  team  members  participate  in  this  activity.  In  addition, 
key  IT  staff  members  can  be  included  if  the  analysis  team  needs  to 
enhance  its  knowledge  and  skills  in  information  technology.  These 
additional  people  can  be  a  part  of  the  organization,  or  they  can  be 
from  an  external  organization.  It  is  important  to  ensure  that  the  over¬ 
all  team  participating  in  this  activity  has  both  an  understanding  of  the 
legitimate  business  uses  of  the  critical  assets  and  an  understanding  of 
the  underlying  computing  infrastructure  for  the  organization. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
P2.1:  Select  Infrastructure  Components  to  Evaluate. 


Inputs 

•  Current  knowledge  of 
analysis  team 


P2.1 

Select  Infrastruc¬ 
ture  Components  to 
Evaluate 


Current  knowledge  of 
key  IT  personnel 

Current  network 
topology  diagram 
(IP2-1_1) 

Technology  informa¬ 
tion  (IP2,1_2) 

Critical  assets 
(OPi.4_l) 

Threat  profile  for  criti¬ 
cal  assets  (OP1.6_l) 


- ► 

Outputs 

Infrastructure  compo¬ 
nents  to  examine 
(OP2.1^1) 

Selected  approach  for 
evaluating  each  infra¬ 
structure  component 
(OP2.1_2) 

Key  classes  of  compo¬ 
nents  (OP2.1_3)* 


*  Note:  Key  classes  of  components  is  optional.  Infrastructure  components  can  be  selected  without 
first  identifying  key  classes. 


Importance  Selected  infrastructure  components  are  those  that  are  being  evaluated 

for  technology  vulnerabilities.  This  activity  is  important  because  it 
sets  the  requirements  for  and  the  scope  of  the  vulnerability  evalua¬ 
tion  in  Activity  P2.2. 
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P2.2  Run  Vulnerability  Evaluation  Tools 


Activity  Description  The  goal  of  Activity  P2.2  is  to  identify  the  technology  vulnerabilities 
present  on  each  selected  infrastructure  component  and  to  create  a 
preliminary  summary  of  the  vulnerabilities  that  are  found.  The  fol¬ 
lowing  key  questions  must  be  answered  during  this  activity.  The 
questions  focus  on  summarizing  technology  vulnerabilities  according 
to  when  they  need  to  be  addressed. 

Key  Questions  for  P2.2;  Run  Vulnerability  Evaluation  Tools 

•  Which  technology  vulnerabilities  are  present  on  each  evaluated 
infrastructure  component? 

•  For  each  evaluated  component,  how  many  technology  vulner¬ 
abilities  must  be  addressed  immediately? 

•  For  each  evaluated  component,  how  many  technology  vulner¬ 
abilities  must  be  addressed  soon? 

•  For  each  evaluated  component,  how  many  technology  vulner¬ 
abilities  can  be  addressed  later?  _ _ 

To  answer  the  first  key  question,  the  people  who  conduct  the  vulner¬ 
ability  evaluation  must  evaluate  the  organization’s  computing  infra¬ 
structure  in  relation  to  a  catalog  of  vulnerabilities.  (See  Attribute 
RA.5,  Catalog  of  Vulnerabilities,  of  the  OCTAVE  criteria).  This  al¬ 
lows  an  organization  to  evaluate  its  technology  base  against  known 
technology  vulnerabilities,  providing  the  organization  with  informa¬ 
tion  about  how  vulnerable  its  computing  infrastructure  currently  is. 

During  Activity  P2.2,  specific  infrastructure  components  are  evalu¬ 
ated  for  technology  vulnerabilities.  The  people  leading  this  activity 
(members  of  the  analysis  team  with  an  IT  background  or  supplemen¬ 
tal  personnel)  run  vulnerability  evaluation  tools  on  each  selected  in¬ 
frastructure  components  identified  during  Activity  P2.1.  Those  indi¬ 
viduals  then  review  the  detailed  vulnerability  information  generated 
by  the  tool(s),  interpret  the  results,  and  create  a  preliminary  summary 
of  the  technology  vulnerabilities  for  each  key  component. 
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Participants  The  analysis  team  members  participate  in  this  activity.  In  addition, 

key  information  technology  staff  members  can  be  included  if  the 
analysis  team  needs  to  enhance  its  knowledge  and  skills  in  informa¬ 
tion  technology.  These  additional  people  can  be  a  part  of  the  organi¬ 
zation  or  can  be  from  an  external  organization.  It  is  important  to  en¬ 
sure  that  the  individuals  leading  this  activity  have  an  in-depth 
understanding  of  information  technology  and  computer  security  is¬ 
sues. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

P2.2:  Run  Vulnerability  Evaluation  Tools. 


- ► 

Inputs 

•  Current  knowledge  of 
analysis  team 

•  Current  knowledge  of 
key  IT  personnel 

•  Catalog  of  vulnerabili¬ 
ties  (IP2.2_1) 


- 

P2.2 

Run  Vulnerability 
Evaluation  Tools 


V _ J 


- ► 

Outputs 

•  Technology  vulnerabili 
ties  (OP2.2_l) 

•  Proposed  technology 
vulnerability  summary 
(OP2.2_2) 


•  Current  network  to¬ 
pology  diagram 
(IP2.1_1) 

•  Technology  informa¬ 
tion  (IP2.1_2) 


•  Infrastructure  compo¬ 
nents  to  examine 
(OP2.1_l) 

•  Selected  approach  for 
evaluating  each  infra¬ 
structure  component 
(OP2.1_2) 


Importance  Technology  vulnerabilities  are  weaknesses  in  systems  that  can  di¬ 

rectly  lead  to  unauthorized  action.  These  vulnerabilities  are  present 
in  and  apply  to  network  services,  architecture,  operating  systems,  and 
applications.  This  activity  is  important  because  it  helps  organizations 
to  identify  specific  weaknesses  in  their  computing  infrastructure  that 
could  be  exploited  by  threat  actors. 


CMU/SEI-2001-TR-016 


77 


P2.3  Review  Vulnerabilities  and  Summarize  Results 


Activity  Description 


Participants 


The  goals  of  Activity  P2.3  are  to  develop  a  summary  of  the  technol¬ 
ogy  vulnerabilities  affecting  each  critical  asset  and  to  refine  the 
threat  profile  for  each  critical  asset  based  upon  the  evaluation  of  that 
asset’s  key  infrastructure  components.  The  following  key  questions 
must  be  answered  during  this  activity.  The  questions  focus  on  the 
vulnerability  summaries  and  their  effect  on  the  organization. 

Key  Questions  for  P2.3:  Review  Vulnerabilities  and  Summarize 

Results 

•  Are  there  any  changes  to  the  proposed  vulnerability  summary  for 
each  critical  asset?  What  are  these  changes? 

•  Are  there  any  specific  actions  or  recommendations  for  address¬ 
ing  the  technology  vulnerabilities  affecting  each  critical  asset? 
What  are  these  actions  or  recommendations? 

•  Do  the  technology  vulnerabilities  associated  with  each  critical 
asset’s  key  infrastructure  components  indicate  the  existence  of 
threats  that  were  previously  believed  to  be  negligible?  What  are 
these  threats? 

During  Activity  P2.3,  a  technology  vulnerability  summary  is  created 
for  each  critical  asset.  The  people  who  conducted  the  vulnerability 
evaluation  (either  members  of  the  analysis  team  with  an  information 
technology  background  or  supplemental  personnel)  review  the  pro¬ 
posed  summary  for  each  critical  asset  with  the  analysis  team,  ensur¬ 
ing  that  all  analysis  team  members  understand  the  results.  Changes  to 
the  summary  can  be  proposed  and  incorporated,  if  appropriate.  In 
addition,  the  team  identifies  and  records  specific  actions  and  recom¬ 
mendations  for  addressing  the  technology  vulnerabilities.  Finally,  the 
team  performs  a  gap  analysis  of  the  threat  profile  for  each  critical 
asset,  refining  the  threat  profile  based  upon  the  evaluation  of  the 
critical  asset’s  key  infrastructure  components. 


The  analysis  team  members  participate  in  this  activity.  In  addition, 
key  IT  staff  members  can  be  included  if  the  analysis  team  needs  to 
enhance  its  knowledge  and  skills  in  information  technology.  These 
additional  people  can  be  a  part  of  the  organization,  or  they  can  be 
from  an  external  organization.  It  is  important  to  ensure  that  the  indi¬ 
viduals  leading  this  activity  have  an  in-depth  understanding  of  in- 
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formation  technology  and  computer  security  issues.  The  people  who 
led  Activity  P2.1  must  be  involved  in  this  activity. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

P2.3:  Review  Vulnerabilities  and  Summarize  Results. 


- ► 

Outputs 

•  Technology  vulner¬ 
ability  summary 
(OP2.3^1) 

•  Threat  profile  for  critical 
assets  (OP2.3_2) 

•  Technology  informa¬ 
tion  (IP2.1_2) 

•  Threat  profiles  for 
critical  assets 
(OPL6^1) 

•  Infrastructure  compo¬ 
nents  to  examine 
(OP2.1_l) 

•  Selected  approach  for 
evaluating  each  infra¬ 
structure  component 
(OP2.1_2) 

•  Proposed  technology 
vulnerability  summary 
(OP2.2„2) 


Inputs 

•  Current  knowledge  of 
analysis  team 

•  Current  knowledge  of 
key  IT  personnel 

•  Current  network  to¬ 
pology  diagram 
(IP2.1_1) 


P2.3 

Review  Vulnerabili¬ 
ties  and  Summarize 
Results 


Importance  A  technology  vulnerability  summary  contains  a  description  of  the 

types  of  vulnerabilities  found,  when  they  need  to  be  addressed,  and 
specific  actions  or  recommendations  for  addressing  them.  This  activ¬ 
ity  is  important  because  it  captures  the  present  state  of  the  computing 
infrastructure  with  respect  to  technological  weaknesses  that  could  be 
exploited  by  human  threat  actors. 
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A.3  Phase  3  (Develop  Security  Strategy  and  Plans) 
Activities 

Phase  3  of  OCTAVE  is  entitled  Develop  Security  Strategy  and  Plans.  During  this  part  of  the 
evaluation,  the  analysis  team  identifies  risks  to  the  organization’s  critical  assets  and  decides 
what  to  do  about  them.  The  team  analyzes  the  information  generated  during  the  evaluation 
and  proposes  a  protection  strategy  for  organizational  improvement  and  risk  mitigation  plans 
to  address  the  risks  to  the  critical  assets.  The  organization’s  senior  managers  review  the  pro¬ 
posed  strategy  and  plans  and  refine  them  as  appropriate,  based  on  organizational  resources 
and  constraints.  The  senior  managers  then  determine  the  next  steps  required  to  implement  the 
protection  strategy  and  the  mitigation  plans.  During  Phase  3,  the  analysis  team 

•  identifies  risks  to  the  organization’s  critical  assets 

•  develops  priorities  based  on  evaluating  the  risks  against  established  evaluation  criteria 

•  develops  a  proposed  protection  strategy  for  organizational  security  improvement 

•  develops  proposed  risk  mitigation  plans  to  address  the  risks  to  the  critical  assets 

During  Phase  3,  the  senior  managers 

•  review  and  refine  the  proposed  protection  strategy 

•  review  and  refine  proposed  risk  mitigation  plans 

•  develop  the  next  steps  required  to  implement  the  protection  strategy  and  the  mitigation 
plans 

Phase  3  is  composed  of  the  following  seven  activities: 

P3. 1  Identify  Risks  to  Critical  Assets 

P3.2  Create  Risk  Evaluation  Criteria 

P3.3  Evaluate  Risks  to  Critical  Assets 

P3.4  Create  Protection  Strategy 

P3.5  Create  Risk  Mitigation  Plans 

P3.6  Review  Protection  Strategy  and  Risk  Mitigation  Plans  with  Management 

P3.7  Identify  Next  Steps 

We  describe  each  activity  in  the  remainder  of  this  section. 
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P3.1  Identify  Risks  to  Criticai  Assets 


Activity  Description  The  goal  of  Activity  P3. 1  is  to  describe  the  potential  impacts  to  the 
organization  for  the  possible  threat  outcomes  in  each  Critical  asset’s 
threat  profile.  An  optional  goal  is  to  gather  probability  data  for  the 
threats  in  each  critical  asset’s  threat  profile.  The  following  key  ques¬ 
tions  must  be  answered  during  this  activity.  The  questions  focus  on 
how  threats  affect  the  organization’s  business  objectives  and  mission. 

Key  Questions  for  P3.1;  Identify  Risks  to  Critical  Assets 

(Impact) 

For  each  critical  asset,  based  on  the  threat  outcomes; 

•  What  is  the  potential  impact  to  the  organization’s  reputation? 

•  What  is  the  potential  impact  on  customer  confidence? 

•  What  is  the  potential  impact  to  the  customers’  health? 

•  What  is  the  potential  impact  to  the  organization’s  productiv¬ 
ity? 

•  What  fines  or  legal  penalties  could  be  imposed  on  the  or¬ 
ganization? 

•  What  would  be  the  financial  impact  to  the  organization? 

During  Activity  P3.1,  risks  are  identified  for  each  critical  asset.  The 
analysis  team  reviews  the  threat  profile  for  each  critical  asset.  For 
each  threat  outcome  (disclosure,  modification,  loss/destruction,  inter¬ 
ruption)  present  in  the  profile,  the  team  creates  a  narrative  descrip¬ 
tion  of  the  potential  impacts  to  the  organization. 

Using  probability  during  the  risk  analysis  is  optional.  If  it  is  being 
used,  then  the  analysis  team  describes  the  motive,  means,  and  oppor¬ 
tunity  for  human  actors  using  either  network  or  physical  access, 
compiles  any  historical  data  for  all  threat  types,  and  notes  any  un¬ 
usual  current  conditions  that  can  affect  threats.  If  probability  is  used, 
then  the  following  key  questions  must  be  answered  during  the  activ¬ 
ity.  The  questions  focus  on  the  factors  that  contribute  to  determining 
probability.  See  the  Notes  area  below  for  additional  thoughts  about 
incorporating  probability  into  the  risk  analysis. 
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Participants 


Optional  Key  Questions  for  P3.1:  Identify  Risks  to  Critical 

Assets  (Probability) 

For  each  threat  profile: 

•  Which  critical  assets  are  likely  targets  of  human  threat  ac¬ 
tors? 

•  What  are  the  motives,  means,  and  opportunities  for  each 
human  threat  actor  that  might  use  network  access  to  violate 
the  security  requirements  of  the  critical  asset? 

•  What  are  the  motives,  means,  and  opportunities  for  each 
human  threat  actor  that  might  use  physical  access  to  violate 
the  security  requirements  of  the  critical  asset? 

•  What  historical  data  are  available  for  the  threats  in  the  threat 
profile? 

•  What  unusual  current  conditions  or  circumstances  might  af¬ 
fect  the  probability  of  the  threats  in  the  threat  profile? 


The  analysis  team  members  are  the  key  participants  in  this  activity.  If 
appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
P3.1:  Identify  Risks  to  Critical  Assets. 


f  P3.1 


Inputs 


Identify  Risks  to 
Critical  Assets 


Current  knowledge  of 
analysis  team 


•  Critical  assets 
(OP1.4_l) 


•  Security  requirements 
for  critical  assets 
(OP1.5_l) 

•  Threat  profile  for  criti¬ 
cal  assets  (OP2.4_2) 


- ► 

Outputs 

•  Impact  descriptions 
of  threats  to  critical 
assets  (OP3.1_l) 

•  Probability  data  for 
threats  to  critical 
assets  (OP3. 1_2)* 


Note:  Probability  is  optional.  The  risk  analysis  can  be  performed  using  only  impact. 


Importance  The  essential  risk  property  is  impact,  which  describes  the  effect  of 

threats  on  the  organization’s  mission  and  business  objectives.  This 
activity  is  important  because  it  focuses  on  the  effect  of  threats  on  the 
organization  by  putting  threats  into  the  context  of  what  the  organiza¬ 
tion  is  trying  to  achieve.  It  forms  the  basis  for  setting  priorities  dur¬ 
ing  later  activities.  If  probability  is  also  being  used,  the  probability 
data  gathered  during  this  activity  are  important  because  they  can  be 
used  to  refine  priorities.  See  the  Notes  area  below  for  additional 
thoughts  about  incorporating  probability  into  the  risk  analysis. 


Notes  For  information  security  risks,  probability  is  a  more  complex  and 

imprecise  variable  than  is  normally  found  in  other  risk  management 
domains,  because  risk  factors  are  constantly  changing.  Probability  is 
highly  subjective  in  the  absence  of  objective  data  and  must  be  used 
carefully  during  risk  analysis.  Impact  values  are  used  as  the  primary 
factor  behind  setting  priorities  in  OCTAVE.  Probability  values  can  be 
factored  into  prioritization,  but  care  must  be  taken  when  doing  so.  A 
subjective  view  of  probability  can  refine  the  understanding  of  threat 
by  focusing  on  information  about  motives,  means,  opportunities,  his¬ 
torical  data,  and  any  unusual  conditions. 
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P3.2  Create  Risk  Evaluation  Criteria 


Activity  Description  The  goal  of  Activity  P3.2  is  to  define  the  risk  evaluation  criteria  for 
the  risk’s  impact,  establishing  a  common  understanding  of  the  quali¬ 
tative  measures  of  impact.  An  optional  goal  is  to  define  the  risk 
evaluation  criteria  for  probability,  establishing  a  common  under¬ 
standing  of  the  qualitative  measures  of  probability.  The  following 
key  questions  must  be  answered  during  this  activity.  The  questions 
focus  on  defining  measures  of  impact. 

Key  Questions  for  P3.2:  Create  Risk  Evaluation  Criteria 

(Impact) 

•  What  defines  a  “high”  impact  to  the  organization? 

•  What  defines  a  “medium”  impact  to  the  organization? 

•  What  defines  a  “low”  impact  to  the  organization? 

During  Activity  P3.2,  risk  evaluation  criteria  are  created.  The  analy¬ 
sis  team  determines  what  constitutes  high,  medium,  and  low  impacts 
to  the  organization,  considering  a  variety  of  potential  impact  areas. 

Using  probability  during  the  risk  analysis  is  optional.  If  it  is  being 
used,  then  the  analysis  team  determines  what  constitutes  high,  me¬ 
dium,  and  low  probabilities  for  threats.  When  establishing  evaluation 
criteria  for  probability,  the  team  considers  information  about  motive, 
means,  and  opportunity  for  human  actors  using  either  network  or 
physical  access,  any  historical  data  for  all  threat  types,  and  any  un¬ 
usual  current  conditions  that  can  affect  threats.  If  probability  is  used, 
then  the  following  key  questions  must  be  answered  during  the  activ¬ 
ity.  The  questions  focus  on  defining  measures  of  probability. 

Optional  Key  Questions  for  P3.2:  Create  Risk  Evaluation 

Criteria  (Probability) 

•  What  defines  a  “high”  likelihood  of  occurrence? 

•  What  defines  a  “medium”  likelihood  of  occurrence? 

•  What  defines  a  “low”  likelihood  of  occurrence? 
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Participants 


The  analysis  team  members  are  the  key  participants  in  this  activity.  If 
appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

P3.2:  Create  Risk  Evaluation  Criteria. 


f  P3.2  1 


Inputs 


Current  knowledge  of 
analysis  team 

Impact  descriptions  of 
threats  to  critical  assets 
(OP3.1_l) 


V. 


Create  Risk  Evalua¬ 
tion  Criteria 


► 


Outputs 


Evaluation  criteria 
for  impact  (OP3.2_l) 


•  Evaluation  criteria  for 
probability  (OP3.2_2)* 


•  Probability  data  for 
threats  to  critical  assets 
(OP3.1_2)* 


*  Note:  Probability  is  optional.  The  risk  analysis  can  be  performed  using  only  impact. 


Importance  Evaluation  criteria  are  a  set  of  qualitative  measures  against  which 

impact  and  probability  are  evaluated.  This  activity  is  important  be¬ 
cause  it  establishes  the  criteria  for  what  constitutes  high,  medium, 
and  low  impacts  to  an  organization.  In  Activity  P3.3,  the  impact  de¬ 
scriptions  from  Activity  P3.1  are  evaluated  against  the  criteria  gener¬ 
ated  during  this  activity,  yielding  impact  values.  Impact  values  are 
used  to  establish  priorities  during  risk  mitigation.  Thus,  it  is  impor¬ 
tant  to  establish  criteria  that  are  meaningful  to  the  organization.  If 
probability  is  also  being  used,  this  activity  also  establishes  what  con¬ 
stitutes  high,  medium,  and  low  probabilities  for  each  threat.  In  Activ¬ 
ity  P3.3,  the  probability  data  from  Activity  P3.1  are  evaluated  against 
the  criteria  generated  during  this  activity,  yielding  probability  values. 
Probability  values  can  be  used  to  refine  the  priorities  that  were  estab¬ 
lished  using  impact. 
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Notes 


Evaluation  criteria  are  qualitative  measures  against  which  impact  and 
probability  are  evaluated.  The  evaluation  criteria  used  to  evaluate 
impact  and  probability  are  the  same  for  all  critical  assets. 


For  impact,  evaluation  criteria  are  created  for  a  broad  range  of  impact 
types,  or  categories.  Evaluation  criteria  are  typically  created  for  the 
following  categories  of  impact: 

•  reputation/customer  confidence 

•  safety/health  issues 

•  fines/legal  penalties 

•  financial  impact 

•  productivity 

The  impact  areas  are  contextual  and  should  be  tailored  to  meet  the 
needs  of  each  organization.  Before  conducting  an  evaluation,  the 
analysis  team  needs  to  determine  which  impact  areas  to  consider. 

One  way  to  determine  unique  areas  for  an  organization  is  to  consider 
the  organization’s  business  objectives  and  make  sure  that  impact  ar¬ 
eas  are  linked  to  those  business  objectives. 
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P3.3  Evaluate  Risks  to  Critical  Assets 


Activity  Description  The  goal  of  Activity  P3.3  is  to  establish  impact  values  (high,  me¬ 
dium,  or  low)  for  each  impact  description,  completing  the  risk  profile 
for  each  critical  asset.  An  optional  goal  is  to  establish  probability 
values  (high,  medium,  or  low)  for  each  threat.  The  following  key 
questions  must  be  answered  during  this  activity.  The  questions  focus 
on  using  the  measures  of  impact  to  determine  the  value  for  each  im¬ 
pact. 

Key  Questions  for  P33:  Evaluate  Risks  to  Critical  Assets 

(Impact) 

For  each  impact  description: 

•  Based  on  the  evaluation  criteria,  is  the  impact  to  the  organi¬ 
zation  “high?” 

•  Based  on  the  evaluation  criteria,  is  the  impact  to  the  organi¬ 
zation  “medium?” 

•  Based  on  the  evaluation  criteria,  is  the  impact  to  the  organi¬ 
zation  “low?” 

During  Activity  P3.3,  impact  values  are  established  for  each  impact 
description.  The  analysis  team  reviews  each  impact  description  and 
then  evaluates  it  against  the  evaluation  criteria  for  impact,  assigning 
the  impact  description  a  value  (high,  medium,  or  low). 

Using  probability  during  the  risk  analysis  is  optional.  If  it  is  being 
used,  then  the  analysis  team  reviews  the  probability  data  for  each 
threat  and  evaluates  the  data  against  the  evaluation  criteria  for  prob¬ 
ability,  assigning  the  threat  a  probability  value  (high,  medium,  or 
low).  When  the  analysis  team  assigns  an  impact  value  to  each  impact 
description  for  a  critical  asset  and,  optionally,  a  probability  value  to 
each  threat  to  the  critical  asset,  it  completes  the  risk  profile  for  that 
critical  asset.  See  the  Notes  area  below  for  additional  information 
about  risk  profiles.  If  probability  is  used,  then  the  following  key 
questions  must  be  answered  during  the  activity.  The  questions  focus 
on  using  the  measures  of  probability  to  determine  the  probability 
value  for  each  threat. 
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Optional  Key  Questions  for  P3.3:  Evaluate  Risks  to  Critical 

Assets  (Probability) 

For  each  threat  in  the  threat  profile: 

•  Based  on  the  evaluation  criteria,  is  the  threat  probability 
“high?” 

•  Based  on  the  evaluation  criteria,  is  the  threat  probability 
“medium?” 

•  Based  on  the  evaluation  criteria,  is  the  threat  probability 
“low?” 


Participants  The  analysis  team  members  are  the  key  participants  in  this  activity.  If 

appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

P3,3:  Evaluate  Risks  to  Critical  Assets. 


P3.3 

Evaluate  Risks  to 
Critical  Assets 


•  Infrastructure  compo¬ 
nents  to  examine 
(OP2.2_l) 

•  Technology 
vulnerability  summary 
(OP2.4_l) 

•  Impact  description  of 
threats  to  critical  assets 
(OP3.1_l) 

•  Probability  data  for 
threats  to  critical  assets 
(OP3.1_2)* 

•  Evaluation  criteria  for 
impact  (OP3.2_l) 

•  Evaluation  criteria  for 
probability  (OP3.2_2)* 


Inputs 

•  Current  knowledge  of 
analysis  team 


- ► 

Outputs 

•  Impact  values  for 
threats  to  critical  assets 
(OP3.3_l) 

•  Probability  values 
for  threats  to  critical 
assets  (OP3.3_2)* 

•  Risk  profiles  for 
critical  assets  (OP3.3_3) 


*  Note:  Probability  is  optional.  The  risk  analysis  can  be  performed  using  only  impact. 
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Importance 


Notes 


Impact  values  are  qualitative  measures  of  a  risk’s  impact  to  the  or¬ 
ganization  (high,  medium,  or  low).  This  activity  is  important  because 
it  requires  the  analysis  team  to  establish  an  impact  value  for  each 
impact  description  that  was  generated  during  Activity  P3.1.  Impact 
values  are  used  to  establish  priorities  when  developing  risk  mitiga¬ 
tion  plans.  If  probability  is  also  being  used,  this  activity  requires  the 
analysis  team  to  establish  a  probability  value  for  each  threat.  Prob¬ 
ability  values  can  be  used  to  refine  the  priorities  established  using 
impact. 


A  risk  profile  for  a  critical  asset  defines  the  range  of  risks  that  can 
affect  that  asset.  The  risk  profile  for  a  critical  asset  consists  of  the 
following  information: 

•  the  threat  profile  for  that  critical  asset 

•  the  security  requirements  for  that  critical  asset 

•  the  impact  description  of  the  threats  in  the  threat  profile 

•  probability  data  for  the  threats  in  the  threat  profile* 

•  impact  values  for  threats  in  the  threat  profile 

•  probability  values  for  threats  in  the  threat  profile* 

•  infrastructure  components  to  examine  for  the  critical  asset 

•  technology  vulnerability  summary  for  each  infrastructure  com¬ 
ponent  examined 

•  These  items  are  optional.  They  are  part  of  a  risk  profile  only  if 
probability  is  used  during  the  risk  analysis. 


CMU/SEI-2001-TR-016 


89 


P3.4  Create  Protection  Strategy 


Activity  Description  The  goal  of  Activity  P3.4  is  to  create  a  proposed  protection  strategy 
for  the  organization.  Key  questions  derived  from  the  strategic  prac¬ 
tices  in  the  catalog  of  practices  must  be  used  during  this  activity.  The 
following  key  questions  are  examples  of  questions  related  to  strate¬ 
gic  security  practices.  The  questions  focus  on  developing  a  set  of 
strategies  framed  around  the  catalog  of  practices. 


Key  Questions  for  P3.4:  Create  Protection  Strategy 

•  What  training  and  education  initiatives  could  help  the  organiza¬ 
tion  maintain  or  improve  its  security  practices? 

•  What  can  be  done  to  improve  the  way  in  which  security  issues 
are  integrated  with  the  organization’s  business  strategy? 

•  What  can  be  done  to  ensure  that  all  staff  members  understand 
their  security  roles  and  responsibilities? 

•  What  funding  level  is  appropriate  to  support  the  organization’s 
security  needs? 

•  Are  the  organization’s  policies  and  procedures  sufficient  for  its 
security  needs?  How  could  they  be  improved? 

•  Does  the  organization  have  policies  and  procedures  for  protect¬ 
ing  information  when  working  with  external  organizations  (e.g., 
third  parties,  collaborators,  subcontractors,  or  partners)?  What 
can  the  organization  do  to  improve  the  way  in  which  it  protects 
information  when  working  with  external  organizations? 

•  What  can  the  organization  do  to  improve  the  way  in  which  it 
verifies  that  outsourced  security  services,  mechanisms,  and  tech¬ 
nologies  meet  its  needs  and  requirements? 

•  What  can  be  done  to  ensure  that  the  organization  has  defined  and 
tested  business  continuity  and  disaster  recovery  plans?  What  can 
be  done  to  ensure  that  staff  members  are  aware  of  and  under¬ 
stand  the  organization’s  business  continuity  and  disaster  recov¬ 
ery  plans? 

During  Activity  P3.4,  a  proposed  protection  strategy  for  the  organiza¬ 
tion  is  developed.  The  analysis  team  reviews  the  current  security 
practices  used  by  the  organization,  the  current  organizational  vulner¬ 
abilities  present  in  the  organization,  and  the  risk  profile  for  each 
critical  asset.  The  team  starts  to  develop  a  protection  strategy  by  con¬ 
sidering  the  strategic  practice  areas  of  the  catalog  of  practices.  The 
team  looks  for  strategies  that  help  the  organization  maintain  its  cur- 
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rent  security  practices,  address  its  organizational  vulnerabilities,  and 
address  its  highest  priority  risks.  The  analysis  team  then  looks  at  the 
major  operational  practice  areas  of  the  catalog  and  determines  any 
additional  strategies  that  could  enable  personnel  in  the  organization 
to  better  understand  and  carry  out  their  security  responsibilities  in 
those  areas. 


Participants  The  analysis  team  members  are  the  key  participants  in  this  activity.  If 

appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

P3.4:  Create  Protection  Strategy. 


r 


P3.4 


Inputs 


Create  Protection 
Strategy 


•  Current  knowledge  of 
analysis  team 


V. 


•  Catalog  of  practices 
(IPL2^3) 

•  Current  security  prac¬ 
tices  (OPl.2^1) 


•  Current  organizational 
vulnerabilities 
(OPl.S^l) 


•  Risk  profiles  for  criti¬ 
cal  assets  (OP3.3__3) 


- ► 

Outputs 

•  Proposed  protection 
strategy  (OP3.4_l) 


Importance  A  protection  strategy  defines  the  strategies  that  an  organization  uses 

to  enable,  initiate,  implement,  and  maintain  its  internal  security.  This 
activity  is  important  because  it  requires  the  analysis  team  to  create  a 
strategy  based  on  the  information  that  it  has  gathered  during  the 
evaluation.  The  proposed  protection  strategy  represents  a  proposal  to 
the  organization’s  management  by  the  analysis  team.  The  strategy  is 
used  to  focus  Activity  P3.6,  Review  Protection  Strategy  and  Risk 
Mitigation  Plans  with  Management,  where  the  organization’s  senior 
managers  review  and  refine  the  proposed  strategy. 
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Notes 


After  the  risk  mitigation  plans  are  created  in  Activity  P3.5,  the  analy¬ 
sis  team  should  make  sure  that  the  strategies  in  the  protection  strat¬ 
egy  and  the  actions  in  the  risk  mitigation  plans  complement  each 
other.  The  team  can  also  look  at  common  themes  among  the  protec¬ 
tion  strategy  and  mitigation  plans  to  get  a  feel  for  high-priority 
strategies  and  actions  to  implement  a'fter  the  evaluation. 
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P3.5  Create  Risk  Mitigation  Pians 


Activity  Description  The  goal  of  Activity  P3.5  is  to  create  proposed  risk  mitigation  plans 
to  reduce  the  risks  to  the  critical  assets.  The  following  key  questions 
must  be  answered  during  this  activity  for  each  category  of  threat  as 
defined  in  the  threat  profile.  The  questions  focus  on  the  organiza¬ 
tion’s  ability  to  recognize,  resist,  and  recover  from  threats  to  the  or¬ 
ganization’s  critical  assets. 


Key  Questions  for  P3.5:  Create  Risk  Mitigation  Plans 
For  each  critical  asset: 

•  Which  are  the  high-priority  risks  to  the  critical  asset?  Which 
threat  types  would  cause  the  largest  impact  to  the  organiza¬ 
tion’s  mission  and  business  objectives? 

•  Which  risks  will  the  organization  actively  mitigate  by  im¬ 
plementing  actions  intended  to  counteract  the  associated 
threat  type?  Which  risks  will  the  organization  accept  and 
take  no  action  to  address? 

•  What  actions  could  be  taken  to  help  recognize  or  detect  the 
threat  types  as  they  occur? 

•  What  actions  could  be  taken  to  help  resist  or  prevent  the 
threat  types  from  occurring? 

•  What  actions  could  be  taken  to  help  recover  from  the  threat 
types  if  they  occur? 

•  What  other  actions  could  be  taken  to  address  these  threat 
types? 

•  What  measures  could  be  used  to  verify  that  this  mitigation 
plan  works  and  is  effective? 


During  Activity  P3.5,  proposed  risk  mitigation  plans  to  reduce  the 
risks  to  the  critical  assets  are  developed.  The  analysis  team  reviews 
the  current  security  practices  used  by  the  organization,  the  current 
organizational  vulnerabilities  present  in  the  organization,  and  the  risk 
profile  for  each  critical  asset.  For  each  critical  asset,  the  team  deter¬ 
mines  which  risks  the  organization  will  actively  mitigate  by  imple¬ 
menting  actions  intended  to  counteract  the  associated  threat  type  and 
which  risks  the  organization  will  accept  and  take  no  further  action  to 
address.  The  team  uses  impact  values  when  it  determines  whether  to 
accept  or  mitigate  a  risk.  If  probability  is  also  being  used,  probability 
values  can  be  factored  into  the  decision  as  well.  For  risks  that  are 
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being  mitigated,  the  team  develops  risk  mitigation  plans  by  identify¬ 
ing  mitigation  actions  designed  to  counter  the  threats  to  the  critical 
assets.  The  team  uses  impact  values  to  establish  mitigation  priorities. 
It  focuses  on  mitigating  the  threats  that  result  in  the  largest  impact  to 
the  organization’s  mission  and  business  objectives.  If  probability  is 
also  being  used  in  the  analysis,  probability  values  can  be  applied  to 
refine  the  priorities  established  using  impact. 


Participants  The  analysis  team  members  are  the  key  participants  in  this  activity.  If 

appropriate,  the  analysis  team  can  include  selected  personnel  to 
augment  its  skills. 


Diagram  The  following  diagram  shows  the  inputs  and  outputs  of  Activity 

P3.5:  Create  Risk  Mitigation  Plans. 


- ► 

Outputs 

•  Proposed  risk  mitiga¬ 
tion  plans  for  critical 
assets  (OP3.5_l) 

•  Current  security  prac¬ 
tices  (OP1.2_l) 

•  Current  organizational 
vulnerabilities 
(OPl-3_l) 

•  Security  requirements 
for  critical  assets 
(OP1.5_l) 

•  Evaluation  criteria  for 
impact  (OP3.2_l) 

•  Evaluation  criteria  for 
probability  (OP3.2_2)* 

•  Risk  profiles  for  criti¬ 
cal  assets  (OP3.3_3) 


P3.5 

.  ^ 

Create  Risk  Mitiga- 

Inputs 

tion  Plans 

•  Current  knowledge  of 
analysis  team 

•  Catalog  of  practices 
(IP1.2_3) 

*  Note:  Probability  is  optional.  Risk  mitigation  plans  can  be  created  using  only  impact. 
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Importance 


Notes 


Risk  mitigation  plans  for  critical  assets  define  the  actions  intended  to 
reduce  the  risks  to  the  critical  assets.  This  activity  is  important  be¬ 
cause  it  requires  the  analysis  team  to  create  a  risk  mitigation  plan  for 
each  critical  asset  based  on  the  information  that  it  has  gathered  dur¬ 
ing  the  evaluation.  The  proposed  risk  mitigation  plans  represent  pro¬ 
posals  to  the  organization’s  management  by  the  analysis  team.  The 
plans  are  used  to  focus  Activity  P3.6,  Review  Protection  Strategy  and 
Risk  Mitigation  Plans  with  Management,  where  the  organization’s 
senior  managers  review  and  refine  the  proposed  plans. 


After  this  activity  has  been  completed,  the  analysis  team  should  make 
sure  that  the  strategies  in  the  protection  strategy  and  the  actions  in  the 
risk  mitigation  plans  complement  each  other.  The  team  can  also  look 
at  common  themes  among  the  protection  strategy  and  mitigation 
plans  to  get  a  feel  for  high-priority  strategies  and  actions  to  imple¬ 
ment  after  the  evaluation. 
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P3.6  Review  Protection  Strategy  and  Risk  Mitigation  Plans 
with  Management 


Activity  Description  The  goal  of  Activity  P3.6  is  for  the  organization’s  senior  managers  to 
review  the  proposed  protection  strategy  and  risk  mitigation  plans 
with  the  analysis  team  and  to  refine  them  as  appropriate.  The  follow¬ 
ing  key  questions  must  be  answered  during  the  activity.  The  ques¬ 
tions  focus  on  the  content  of  the  protection  strategy  and  risk  mitiga¬ 
tion  plans  in  relation  to  the  organizational  resources  and  constraints. 

Key  Questions  for  P3.6:  Review  Protection  Strategy  and  Risk 

Mitigation  Plans  with  Management 

Based  on  organizational  resources  and  constraints: 

•  What  refinements,  modifications,  additions,  or  deletions 
must  be  made  to  the  protection  strategy? 

•  What  refinements,  modifications,  additions,  or  deletions 
must  be  made  to  each  risk  mitigation  plan? 

During  Activity  P3.6,  the  development  of  a  protection  strategy  for 
the  organization  and  risk  mitigation  plans  to  reduce  the  risks  to  the 
critical  assets  is  completed.  The  analysis  team  presents  the  proposed 
protection  strategy  and  proposed  risk  mitigation  plans  to  the  organi¬ 
zation’s  senior  managers.  The  senior  managers  then  make  any  neces¬ 
sary  refinements,  modifications,  additions,  or  deletions  to  the  pro¬ 
posed  protection  strategy  and  risk  mitigation  plans,  taking  into 
account  organizational  resources  and  constraints.  The  result  is  the 
final  version  of  the  protection  strategy  and  risk  mitigation  plans. 


Participants  The  organization’s  senior  managers  are  the  key  participants  in  this 

activity.  The  analysis  team  members  facilitate  the  activity,  ensuring 
that  the  activity  is  completed  satisfactorily.  If  appropriate,  the  analy¬ 
sis  team  can  include  selected  personnel  to  augment  its  skills. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
P3.6:  Review  Protection  Strategy  and  Risk  Mitigation  Plans  with 
Management. 


Inputs 

•  Current  knowledge  of 
analysis  team 


P3.6 

Review  Protection 
Strategy  and  Risk 
Mitigation  Plans 
with  Management 

V _ I _ ) 


- ► 

Outputs 

•  Protection  strategy 
(OP3.6^1) 


Current  knowledge  of 
management 


•  Risk  mitigation  plans  for 
critical  assets  (OP3.6_2) 


Current  security  prac¬ 
tices  (OP1.2_l) 


Current  organizational 

vulnerabilities 

(OPl.3^1) 


Risk  profiles  for  criti¬ 
cal  assets  (OP3.3_3) 

Proposed  protection 
strategy  (OP3.4_l) 

Proposed  risk  mitiga¬ 
tion  plans  for  critical 
assets  (OP3.5_l) 


Importance  A  protection  strategy  defines  the  strategies  that  an  organization  uses 

to  enable,  initiate,  implement,  and  maintain  its  internal  security.  Risk 
mitigation  plans  for  critical  assets  define  the  mitigation  actions  in¬ 
tended  to  reduce  the  risks  to  the  critical  assets.  This  activity  is  impor¬ 
tant  because  it  requires  the  organization’s  senior  managers  to  review 
the  proposed  protection  strategy  and  risk  mitigation  plans  from  the 
organizational  perspective.  The  senior  managers  then  refine  the  strat¬ 
egy  and  plans  based  on  the  managers’  understanding  of  organiza¬ 
tional  resources  and  constraints.  This  activity  is  also  important  for 
developing  senior  management  sponsorship  of  the  protection  strategy 
and  risk  mitigation  plans. 


CMU/SEI-2001-TR-016 


97 


P3.7  Identify  Next  Steps 


Activity  Description 


Participants 


The  goal  of  Activity  P3.7  is  for  the  organization’s  senior  managers  to 
identify  next  steps  that  will  be  taken  to  implement  the  protection 
strategy  and  the  mitigation  plans.  The  following  key  questions  must 
be  answered  during  this  activity.  The  questions  focus  on  manage¬ 
ment’s  role  in  enabling  ongoing  security  improvement. 

Key  Questions  for  P3. 7:  Identify  Next  Steps 

•  What  will  the  organization  do  to  build  on  the  results  of  this 
evaluation? 

•  What  else  will  management  do  to  ensure  that  the  organization 
improves  its  information  security? 

•  What  can  management  do  to  support  this  security  improvement 
initiative? 

•  What  are  management’s  plans  for  ongoing  security  evaluation 
activities? 

During  Activity  P3.7,  the  next  steps  required  to  implement  the  pro¬ 
tection  strategy  and  the  mitigation  plans  are  defined.  The  senior 
managers  determine  what  the  organization  will  do  to  implement  the 
results  of  the  evaluation  and  determine  what  the  managers  will  do  to 
enable  security  improvement  in  the  organization.  The  managers  also 
determine  if  there  are  any  other  security  improvement  activities  that 
need  to  be  addressed  and  determine  how  the  organization  will  ap¬ 
proach  future  assessments. 


The  organization’s  senior  managers  are  the  key  participants  in  this 
activity.  The  analysis  team  members  facilitate  the  activity,  ensuring 
that  the  activity  is  completed  satisfactorily.  If  appropriate,  the  analy¬ 
sis  team  can  include  selected  personnel  to  augment  its  skills. 
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Diagram 


The  following  diagram  shows  the  inputs  and  outputs  of  Activity 
P3.7:  Identify  Next  Steps. 


Inputs 

•  Current  knowledge  of 
analysis  team 

•  Current  knowledge  of 
management 

•  Protection  strategy 
(OP3.6^1) 


P3.7 

Identify  Next  Steps 


Outputs 

•  Next  steps  (OP3.7_l) 


•  Risk  mitigation  plans 
for  critical  assets 
(OP3.6_2) 


Importance  The  next  steps  define  what  the  organization  will  do  to  implement  the 

results  of  the  evaluation.  This  activity  is  important  because  it  requires 
management  to  identify  actions  that  enable  ongoing  security  im¬ 
provement.  Without  the  explicit  definition  of  the  steps  required  to 
implement  the  results  of  the  evaluation  and  without  strong  sponsor¬ 
ship  from  senior  management,  the  initiative  to  improve  the  organiza¬ 
tion’s  security  posture  will  likely  fail. 
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A.4  Data  Dictionary  for  Activity  Inputs  and  Outputs 

This  section  contains  a  data  dictionary  that  defines  each  input  and  output  in  the  diagrams  that 
we  presented  in  sections  A.1-A.3.  The  data  items  are  presented  by  activity.  For  an  explanation 
of  the  numbering  scheme,  see  the  introduction  to  this  appendix. 


General 

The  current  knowledge  of  the  organizational  staff  includes 
the  collective  knowledge,  skills,  and  abilities  of  the  people 
who  contribute  their  understanding  of  assets,  current  secu¬ 
rity  requirements,  and  organizational  vulnerabilities.  This 
includes  people  from  both  the  business  and  information 
technology  areas  of  the  organization.  In  addition,  multiple 
organizational  levels  (senior  management,  operational  area 
management,  staff)  must  be  represented. 

The  current  knowledge  of  the  analysis  team  includes  the 
collective  knowledge,  skills,  and  abilities  of  the  analysis 
team  members  and  any  supplemental  personnel  participat¬ 
ing  in  a  specific  activity. 

Current  knowledge  of  key  IT  The  current  knowledge  of  key  IT  personnel  includes  the 
personnel  collective  knowledge,  skills,  and  abilities  of  the  informa¬ 

tion  technology  personnel  who  participate  in  Phase  2  of 
OCTAVE.  These  people  have  an  in-depth  understanding  of 
the  organization’s  computing  infrastructure  as  well  as  in¬ 
formation  security  issues.  These  people  can  be  a  part  of  the 
organization  or  can  be  from  an  external  organization. 


Current  knowledge  of 
organizational  staff 


Current  knowledge  of 
analysis  team 
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Activity  Pl.l  Identify  Assets 

Assets  (OPl.l_l)  This  is  a  listing  of  the  information-related  assets  for  the 

organization.  An  asset  is  something  of  value  to  the  organi¬ 
zation.  The  following  categories  of  assets  are  typically  con¬ 
sidered  during  the  evaluation: 

•  information  -  documented  (paper  or  electronic)  data  or 
intellectual  property  used  to  meet  the  mission  of  the 
organization 

•  systems  -  information  systems  that  process  and  store 
information.  Systems  are  a  combination  of  information, 
software,  and  hardware  assets.  Any  host,  client,  or 
server  can  be  considered  to  be  a  system 

•  software  -  software  applications  and  services  (operat¬ 
ing  systems,  database  applications,  networking  soft¬ 
ware,  office  applications,  custom  applications,  etc.) 

•  hardware  -  information  technology  physical  devices 
(workstations,  servers,  etc.) 

•  people  -  the  people  in  the  organization,  including  their 
skills,  training,  knowledge,  and  experience 


Activity  PI. 2  Identify  Current  Security  Practices 


Organizational  data 
(IP1.1_1) 


Laws  and  regulations 
(1P1.2_1) 


Organizational  data  include 

•  information  about  how  the  organization  is  structured 

•  the  organization’s  currently  documented  policies  and 
procedures  related  to  security 

Laws  and  regulations  define  the  legal  obligations  of  the 
organization  with  respect  to  security. 


Catalog  of  practices  The  catalog  of  practices  defines  the  range  of  security  prac- 

(IP1,2_2)  tices  that  must  be  considered  during  the  evaluation.  The 

requirements  for  the  catalog  of  practices  are  defined  in  the 
OCTAVE  criteria.  (See  OCTAVE  Attribute  RA.3,  Catalog 
of  Practices,  of  the  OCTAVE  criteria.) 


Current  security  practices  Current  security  practices  are  those  actions  presently  used 
(OP1.2_l)  by  the  organization  to  initiate,  implement,  and  maintain  its 

internal  security.  Security  practices  are  used  to  protect  an 
organization’s  information-related  assets. 
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Activity  PI. 3  Identify  Current  Organizational  Vulnerabilities 

Current  organizational  vul-  Current  organizational  vulnerabilities  are  weaknesses  in 
nerabilities  (OP1.3_l)  organizational  policy  or  practice  that  can  result  in  unau¬ 

thorized  actions  occurring.  They  are  indications  of  missing 
or  inadequate  security  practices. 


Activity  P1.4  Identify  Critical  Assets 

Critical  assets  (OP1.4_l)  Critical  assets  are  those  that  are  believed  to  be  the  most 

important  assets  to  the  organization.  The  organization  will 
suffer  a  large  adverse  impact  if  the  security  requirements  of 
these  assets  are  violated. 


Activity  P1.5  Describe  Security  Requirements  for  Critical  Assets 

Security  requirements  for  Security  requirements  for  critical  assets  outline  the  qualities 
critical  assets  (OP1.5_l)  of  the  critical  assets  that  are  important  to  an  organization. 

Security  requirements  considered  during  the  evaluation 
typically  include 

•  confidentiality 

•  integrity 

•  availability 


Activity  P1.6  Create  Threat  Profiles  for  Critical  Assets 

Generic  threat  profile  The  generic  threat  profile  defines  the  range  of  common 

(1P1.6_1)  threats  that  must  be  considered  for  each  critical  asset.  The 

requirements  for  the  generic  threat  profile  are  defined  in  the 
OCTAVE  criteria.  (See  OCTAVE  Attribute  RA.4,  Generic 
Threat  Profile,  of  the  OCTAVE  criteria.) 

Threat  profile  for  critical  The  threat  profile  for  a  critical  asset  defines  the  range  of 
assets  (OP1.6_l)  threats  that  can  affect  that  critical  asset.  Threat  profiles 

contain  categories  that  are  grouped  according  to  threat 
source.  Attributes  of  a  threat  profile  include  asset,  access, 
actor,  motive,  and  outcome.  (Examples  of  threat  categories 
include  human  actors  using  network  access,  human  actors 
using  physical  access,  system  problems,  and  other  prob¬ 
lems). 
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Activity  P2.1 


Select  Infrastructure  Components  to  Evaluate 


Current  network  topology  A  current  network  topology  diagram  consists  of  electronic 

diagram  (IP2.1_1)  or  paper  documents  used  to  display  the  logical  or  physical 

mapping  of  a  network.  These  documents  identify  the  con¬ 
nectivity  of  systems  and  networking  components. 

Technology  information  encompasses  all  detailed  infor¬ 
mation  about  the  organization’s  computing  infrastructure. 
This  includes  the  Internet  Protocol  (IP)  addresses  and  fully 
qualified  domain  names  for  all  infrastructure  components. 

Infrastructure  components  to  Infrastructure  components  to  examine  are  components  that 
examine  (OP2.1_l)  have  been  chosen  for  evaluation.  These  components  are 

evaluated  for  technology  vulnerabilities. 

Selected  approach  for  evalu-  The  selected  approach  for  evaluating  each  infrastructure 
ating  each  infrastructure  component  sets  the  requirements  for  and  the  scope  of  the 

component  (OP2.1_2)  vulnerability  evaluation.  The  following  are  typically  in¬ 

cluded  in  the  approach: 

•  who  will  perform  the  evaluation 

•  which  vulnerability  evaluation  tool(s)  will  be  used 

Key  classes  of  components  are  types  of  devices  that  are 
important  in  processing,  storing,  or  transmitting  critical 
information.  They  represent  related  assets  to  critical  as¬ 
sets.  The  following  classes  of  components  are  typically 
considered  during  the  evaluation: 

•  servers  -  hosts  within  your  IT  infrastructure  that  pro¬ 
vide  IT  services  to  your  organization 

•  networking  components  -  devices  important  to  your 
organization’s  networks.  Routers,  switches,  and  mo¬ 
dems  are  all  examples  of  this  class  of  component. 

•  security  components  -  devices  that  have  security  as 
their  primary  function  (e.g.,  a  firewall) 

•  desktop  workstations  -  hosts  on  your  networks  that 
staff  members  use  to  conduct  business 

•  home  computers  -  home  PCs  that  staff  members  use 
to  access  information  remotely  via  your  organization’s 
networks 

•  laptops  -  portable  PCs  that  staff  members  use  to  ac¬ 
cess  information  remotely  via  your  organization’s 
networks 
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Key  classes  of  components 
(OP2.1_3)* 


Technology  information 
(IP2.1_2) 


Activity  P2.1 
(cont.) 


Select  Infrastructure  Components  to  Evaluate 


•  storage  devices  -  devices  where  information  is  stored. 

Key  classes  of  components  ^  r  ,  , 

^  ,  often  for  backup  purposes 

(OP2.1_3)*  (cont.)  ^ 

•  wireless  components  —  devices,  such  as  cell  phones 
and  wireless  access  points,  that  staff  members  may 
use  to  access  information  (e.g.,  email) 

•  others  -  any  other  type  of  device  that  could  be  part  of 
your  threat  scenarios,  but  does  not  fall  into  the  above 
classes 

*  Note:  Selecting  key  classes  of  components  (OP2.1_3)  is  an  optional  first  step  useful  for 
large  computing  infrastructures.  It  may  not  be  necessary  for  smaller  networks  with  lim¬ 
ited  components.  The  list  of  key  classes  can  be  used  to  help  identify  specific  components 
(OP2.1_l). 

Activity  P2.2  Run  Vulnerability  Evaluation  Tools 

Catalog  of  vulnerabilities  The  catalog  of  vulnerabilities  is  a  collection  of  vulnerabili- 

(IP2.2_1)  ties  based  on  platform  and  application.  It  is  used  to  evalu¬ 

ate  an  organization’s  computing  infrastructure  for  tech¬ 
nology  vulnerabilities.  The  requirements  for  the  catalog  of 
vulnerabilities  are  defined  in  the  OCTAVE  criteria.  (See 
OCTAVE  Attribute  RA.5,  Catalog  of  Vulnerabilities,  of 
the  OCTAVE  criteria.) 

Technology  vulnerabilities  Technology  vulnerabilities  are  weaknesses  in  systems  that 
(OP2.2_l)  can  directly  lead  to  unauthorized  action.  Technology  vul¬ 

nerabilities  are  present  in  and  apply  to  network  services, 
architecture,  operating  systems,  and  applications.  Types  of 
technology  vulnerabilities  include  design,  implementation, 
and  configuration  vulnerabilities. 

Proposed  technology  vulner-  The  proposed  technology  vulnerability  summary  for  each 
ability  summary  (OP2.2_2)  component  typically  contains  the  following  information 

for  each  infrastructure  component  that  is  evaluated: 

•  the  number  of  vulnerabilities  to  fix  immediately  (high- 
severity  vulnerabilities) 

•  the  number  of  vulnerabilities  to  fix  soon  (medium- 
severity  vulnerabilities) 
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•  the  number  of  vulnerabilities  to  fix  later  (low-severity 
vulnerabilities) 

Activity  P2.3  Review  Vulnerabilities  and  Summarize  Results 

Technology  vulnerability  The  technology  vulnerability  summary  for  each  component 
summary  (OP2.3_l)  typically  contains  the  following  information  for  each  infra¬ 

structure  component  that  is  evaluated: 

•  the  number  of  vulnerabilities  to  fix  immediately  (high- 
severity  vulnerabilities) 

•  the  number  of  vulnerabilities  to  fix  soon  (medium- 
severity  vulnerabilities) 

•  the  number  of  vulnerabilities  to  fix  later  (low-severity 
vulnerabilities) 

In  addition,  the  summary  for  each  critical  asset  contains 
specific  actions  or  recommendations  for  addressing  the 
technology  vulnerabilities  that  were  found. 

Threat  profile  for  critical  The  threat  profile  for  a  critical  asset  defines  the  range  of 
assets  (OP23_2)  threats  that  can  affect  that  critical  asset.  Threat  profiles 

contain  categories  that  are  grouped  according  to  threat 
source.  (Examples  of  threat  categories  include  human  ac¬ 
tors  using  network  access,  human  actors  using  physical 
access,  system  problems,  and  other  problems). 
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Activity  P3.1 


Identify  Risk  Properties  for  Threats  to  Critical  As¬ 
sets 


Impact  descriptions  of 
threats  to  critical  assets 
(OP3.1_l) 


The  impact  description  of  a  threat  to  a  critical  asset  defines 
the  effect(s)  of  the  threat  on  the  organization’s  mission  and 
business  objectives. 


Probability  data  for  threats  The  probability  data  for  a  threat  to  a  critical  asset  describe 
to  critical  assets  (OP3.1_2)*  the  motive,  means,  and  opportunity  for  human  actors  using 

either  network  or  physical  access;  compile  any  historical 
data  for  all  threat  types;  and  note  any  unusual  current  con¬ 
ditions  that  can  affect  threats. 


*  Note:  Probability  data  for  threats  to  critical  assets  (OP3.1_2)  is  an  optional  data  item.  See 
Activity  P3.1:  Identify  Risk  Properties  for  Threats  to  Critical  Assets  for  more  informa¬ 
tion. 


Activity  P3.2  Create  Risk  Evaluation  Criteria 


Evaluation  criteria  for  im-  Evaluation  criteria  for  impact  are  a  set  of  qualitative  meas- 
pact  (OP3.2_l)  ures  against  which  a  risk  is  evaluated.  Evaluation  criteria 

define  high,  medium,  and  low  impacts  for  an  organization. 
Evaluation  criteria  are  typically  created  for  the  following 
categories  of  impact: 


•  reputation/customer  confidence 

•  safety/health  issues 

•  fines/legal  penalties 

•  financial  impact 

•  productivity 

Evaluation  criteria  for  prob-  Evaluation  criteria  for  probability  are  a  set  of  qualitative 
ability  (OP3.2_2)*  measures  against  which  a  risk  is  evaluated.  Evaluation  cri¬ 

teria  define  high,  medium,  and  low  probabilities  for  threats 
to  critical  assets. 


*  Note:  Evaluation  criteria  for  probability  (OP3.2_2)  is  an  optional  data  item.  See  Activity 
P3.2:  Create  Risk  Evaluation  Criteria  for  more  information. 
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Activity  P3.3 


Evaluate  Risks  to  Critical  Assets 


Impact  values  for  threats  to  Impact  values  for  threats  to  critical  assets  are  qualitative 

critical  assets  (OP3.3_l)  measures  (high,  medium,  or  low)  of  the  resulting  impact  to 

the  organization’s  mission  and  business  objectives. 


Probability  values  for  threats  Probability  values  for  threats  to  critical  assets  are  qualita- 
to  critical  assets  (OP3.3_2)*  tive  measures  (high,  medium,  or  low)  of  the  likelihood  of 

occurrence. 


Risk  profiles  for  critical  A  risk  profile  for  a  critical  asset  defines  the  range  of  risks 

assets  (OP33_3)  that  can  affect  that  asset.  The  following  items  are  typically 

included  in  the  risk  profile  for  a  critical  asset: 

•  the  threat  profile  for  that  critical  asset 

•  the  security  requirements  for  that  critical  asset 

•  the  impact  description  of  the  threats  in  the  threat  profile 

•  impact  values  for  threats  in  the  threat  profile 

•  infrastructure  components  to  examine  for  the  critical 
asset 

•  technology  vulnerability  summary  for  each  infrastruc¬ 
ture  component  examined 

If  probability  is  used  during  the  risk  analysis,  then  the  fol¬ 
lowing  can  also  be  included  in  the  risk  profile  for  a  critical 
asset: 

•  probability  data  for  the  threats  in  the  threat  profile 

•  probability  values  for  threats  in  the  threat  profile 

*  Note:  Probability  values  for  threats  to  critical  assets  (OP3.3_2)  is  an  optional  data  item. 
See  Activity  P3.3:  Evaluate  Risks  to  Critical  Assets  for  more  information. 
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Activity  P3.4 


Create  Protection  Strategy 


Proposed  protection  strategy  The  proposed  protection  strategy  defines  the  strategies  that 
(OP3.4_l)  the  organization  could  use  to  enable,  initiate,  implement, 

and  maintain  its  internal  security.  It  represents  a  proposal  to 
the  organization’s  management  by  the  analysis  team.  The 
proposed  protection  strategy  tends  to  incorporate  long-term 
organization-wide  initiatives  and  is  structured  using  the 
practice  areas  defined  in  the  catalog  of  practices.  (See 
OCTAVE  Attribute  RA.3,  Catalog  of  Practices,  of  the 
OCTAVE  criteria.) 


Activity  P3.5  Create  Risk  Mitigation  Plans 


Proposed  risk  mitigation  The  proposed  risk  mitigation  plans  for  critical  assets  define 

plans  for  critical  assets  the  mitigation  actions  intended  to  reduce  the  risks  to  the 

(OP3.5_l)  critical  assets.  They  represent  proposals  to  the  organiza¬ 

tion’s  management  by  the  analysis  team.  Risk  mitigation 
plans  tend  to  incorporate  actions,  or  countermeasures,  de¬ 
signed  to  counter  the  threats  to  the  assets.  The  actions  are 
based  on  the  practices  contained  in  the  catalog  of  practices. 
(See  OCTAVE  Attribute  RA.3,  Catalog  of  Practices,  of  the 
OCTAVE  criteria.) 


Activity  P3.6  Review  Protection  Strategy  and  Risk  Mitigation 
Plans  with  Management 

Protection  strategy  The  protection  strategy  defines  the  strategies  that  the  or- 

(OP3.6_l)  ganization  could  use  to  enable,  initiate,  implement,  and 

maintain  its  internal  security.  It  is  the  organization’s  strat¬ 
egy  for  protecting  its  critical  assets,  and  the  analysis  team 
has  incorporated  considerations  of  organizational  resources 
and  constraints  into  the  development  of  this  strategy.  The 
protection  strategy  tends  to  incorporate  long-term  organiza¬ 
tion-wide  initiatives  and  is  structured  using  the  practice 
areas  defined  in  the  catalog  of  practices.  (See  OCTAVE 
Attribute  RA.3,  Catalog  of  Practices,  of  the  OCTAVE  cri¬ 
teria.) 
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Risk  mitigation  plans  for  The  risk  mitigation  plans  for  critical  assets  define  the  miti- 
critical  assets  (OP3.6_2)  gation  actions  intended  to  reduce  the  risks  to  the  critical 

assets.  During  the  development  of  these  plans,  the  analysis 
team  has  considered  organizational  resources  and  con¬ 
straints.  Risk  mitigation  plans  tend  to  incorporate  actions, 
or  countermeasures,  designed  to  counter  the  threats  to  the 
assets.  The  actions  are  based  on  the  practices  contained  in 
the  catalog  of  practices.  (See  OCTAVE  Attribute  RA.3, 
Catalog  of  Practices,  of  the  OCTAVE  criteria.) 


Activity  P3.7  Identify  Next  Steps 


Next  steps  (OP3.7_l)  The  next  steps  define  what  the  organization  will  do  to  im- 

plement  the  results  of  the  evaluation.  Next  steps  typically 
include 

•  what  the  organization  will  do  to  implement  the  results 
of  the  evaluation 

•  what  the  senior  managers  will  do  to  enable  security 
improvement  in  the  organization 

•  whether  there  are  any  other  security  improvement  ac¬ 
tivities  that  need  to  be  addressed 

•  how  the  organization  will  approach  future  assessments 
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Appendix  B:  The  Relationship  Between 

the  OCTAVE  Criteria  and  the 
OCTAVE  Method 


In  this  appendix,  we  examine  the  relationship  between  the  OCTAVE  criteria  and  the 
OCTAVE  Method.  We  begin  by  providing  a  brief  description  of  the  OCTAVE  Method.  You 
can  find  a  more  detailed  description  of  the  method  in  the  OCTAVE  Method  Implementation 
Guide,  v2.0  [Alberts  Ola]. 

B.1  The  OCTAVE  Method 

The  OCTAVE  Method  uses  a  three-phase  approach  to  examine  organizational  and  techno¬ 
logical  issues,  assembling  a  comprehensive  picture  of  an  organization’s  information  security 
needs.  The  method  uses  workshops  to  encourage  open  discussion  and  exchange  of  informa¬ 
tion  about  assets,  security  practices,  and  solutions.  Each  workshop  in  the  OCTAVE  Method  is 
led  by  an  analysis  team,  which  is  an  interdisciplinary  team  consisting  of  personnel  from  the 
business  units  and  the  information  technology  department  of  the  organization. 


Some  preparation  activities  are  necessary  to  establish  a  good  foundation  for  successfully 

completing  the  evaluation.  The  preparation  activities  for  the  OCTAVE  Method  are 

•  Obtain  senior  management  sponsorship  of  OCTAVE.  The  planning  activities  for  the 
OCTAVE  Method  start  with  senior  management  sponsorship.  This  could  require  briefings 
to  senior  managers  to  help  them  understand  the  process. 

•  Select  analysis  team  members.  Representatives  from  both  the  business  and  information 
technology  parts  of  the  organization  will  be  on  the  analysis  team.  The  size  of  the  analysis 
team  is  three  to  five  people.  Senior  managers  should  be  involved  in  the  selection  of  team 
members.  In  addition,  it  is  helpful  if  some  of  the  members  come  from  the  operational  ar¬ 
eas  that  will  be  participating  in  the  evaluation. 

•  Train  analysis  team.  The  analysis  team  needs  to  be  trained  in  the  OCTAVE  Method.  Each 
member  of  the  analysis  team  needs  to  understand  his  or  her  role  during  each  workshop. 

•  Select  operational  areas  to  participate  in  OCTAVE.  A  key  part  of  the  planning  process  is 
selecting  the  operational  areas  that  will  participate  in  the  OCTAVE  Method.  This  scopes 
the  evaluation.  The  analysis  team  will  lead  this  activity  with  senior  management  input. 

•  Select  participants.  Participants  for  the  knowledge  elicitation  workshops  (Processes  1-3) 
need  to  be  selected.  Also,  people  with  special  skills  to  augment  the  analysis  team  at  cer- 
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tain  points  in  the  process  need  to  be  selected.  The  analysis  team  members  will  lead  the 
selection  of  participants.  They  need  to  get  input  from  the  senior  managers  and  from  the 
managers  for  each  of  the  operational  areas  participating  in  the  evaluation. 

•  Coordinate  logistics.  The  analysis  team  members  need  to  ensure  that  rooms  and  equip¬ 
ment  are  available  for  all  workshops. 

•  Brief  all  participants.  The  analysis  team  should  conduct  a  briefing  for  all  participants 
prior  to  their  participation  in  the  process. 

Once  the  preparation  is  completed,  the  organization  is  ready  to  start  the  evaluation.  The  three 

phases  of  the  OCTAVE  Method  and  their  processes  are  described  below. 


Phase  1:  Build  Asset-Based  Threat  Profiles.  This  is  an  organizational  evaluation.  The 
analysis  team  determines  which  assets  are  most  important  to  the  organization  (critical  assets) 
and  identifies  what  is  currently  being  done  to  protect  those  assets.  The  processes  of  Phase  1 
are 


•  Process  1:  Identify  Senior  Management  Knowledge  —  Selected  senior  managers  identify 
important  assets,  perceived  threats,  security  requirements,  current  security  practices,  and 
organizational  vulnerabilities. 

•  Process  2:  Identify  Operational  Area  Management  Knowledge  —  Selected  operational 
area  managers  identify  important  assets,  perceived  threats,  security  requirements,  current 
security  practices,  and  organizational  vulnerabilities. 

•  Process  3:  Identify  Staff  Knowledge  -  Selected  general  and  IT  staff  members  identify 
important  assets,  perceived  threats,  security  requirements,  current  security  practices,  and 
organizational  vulnerabilities. 

•  Process  4:  Create  Threat  Profiles  -  The  analysis  team  analyzes  the  information  from  Pro¬ 
cesses  1  to  3,  selects  critical  assets,  refines  the  associated  security  requirements,  and 
identifies  threats  to  those  assets,  creating  threat  profiles. 

Phase  2:  Identify  Infrastructure  Vulnerabilities  -  This  is  an  evaluation  of  the  information 
infrastructure.  The  analysis  team  examines  key  operational  components  for  weaknesses 
(technology  vulnerabilities)  that  can  lead  to  unauthorized  action  against  critical  assets.  The 
processes  of  Phase  2  are 

•  Process  5:  Identify  Key  Components  -  The  analysis  team  identifies  key  IT  systems  and 
components  for  each  critical  asset.  Specific  instances  are  then  selected  for  evaluation. 

•  Process  6:  Evaluate  Selected  Components  -  The  analysis  team  examines  the  key  systems 
and  components  for  technology  weaknesses.  Vulnerability  tools  (software,  checklists, 
scripts)  are  used.  The  results  are  examined  and  summarized,  looking  for  their  relevance 
to  the  critical  assets  and  their  threat  profiles. 

Phase  3:  Develop  Security  Strategy  and  Plans  —  During  this  part  of  the  evaluation,  the 
analysis  team  identifies  risks  to  the  organization’s  critical  assets  and  decides  what  to  do  about 
them.  The  processes  of  Phase  3  are 
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•  Process  7:  Conduct  Risk  Analysis  -  The  analysis  team  identifies  the  impact  of  threats  to 
critical  assets,  creates  criteria  to  evaluate  the  risks  resulting  from  those  threats,  and 
evaluates  the  impacts  based  on  those  criteria.  This  produces  a  risk  profile  for  each  critical 
asset. 

•  Process  8:  Develop  Protection  Strategy  -  The  analysis  team  creates  a  protection  strategy 
for  organizational  security  improvement  and  mitigation  plans  to  reduce  the  risks  to  criti¬ 
cal  assets  based  upon  an  analysis  of  the  information  gathered.  Senior  managers  then  re¬ 
view,  refine,  and  approve  the  strategy  and  plans.  Finally,  the  senior  managers  define  the 
next  steps  that  outline  how  the  organization  will  build  on  the  results  of  the  evaluation  and 
who  will  be  responsible. 

In  the  next  section,  we  show  how  the  OCTAVE  attributes  are  implemented  in  the  OCTAVE 

Method. 


B.2  Attributes  and  the  OCTAVE  Method 

Recall  that  attributes  are  the  distinctive  qualities,  or  characteristics,  of  the  evaluation.  They 
define  the  basic  elements  of  an  information  security  risk  evaluation  from  both  the  process  and 
organizational  perspectives.  Table  5  shows  how  each  attribute  is  reflected  in  the  OCTAVE 
Method. 


Table  5:  Mapping  of  Attributes  to  the  OCTAVE  Method 


Mapping  of  Attributes  to  the  OCTAVE  Method  I 

Attribute 

Implementation  in  the  OCTAVE  Method 

RA.l  Analysis  Team 

An  interdisciplinary  analysis  team  consisting  of  personnel 
from  the  business  units  and  the  information  technology  de¬ 
partment  leads  the  OCTAVE  Method. 

RA.2  Augmenting  Analy¬ 
sis  Team  Skills 

The  activities  for  the  OCTAVE  Method  are  documented  in 
the  OCTAVE  Method  Implementation  Guide,  V2.0.  Guidance 
about  the  types  of  skills  required  to  conduct  each  process  is 
provided.  If  an  analysis  team  believes  that  it  does  not  possess 
sufficient  knowledge  and  skills  to  conduct  a  process,  it  must 
include  supplementary  personnel  who  possess  the  required 
knowledge  and  skills  for  that  process. 

RA.3  Catalog  of  Practices 

The  OCTAVE  Method  requires  the  organization’s  security 
practices  to  be  evaluated  against  a  defined  catalog  of  prac¬ 
tices.  Worksheets  that  are  consistent  with  the  practices  in  the 
catalog  must  be  used. 

RA.4  Generic  Threat  Pro¬ 
file 

The  OCTAVE  Method  requires  the  threats  to  the  organiza¬ 
tion’s  critical  assets  to  be  evaluated  against  a  generic  threat 
profile.  Worksheets  that  are  consistent  with  the  threats  in  the 
generic  threat  profile  must  be  used. 
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Table  5: 


Mapping  of  Attributes  to  the  OCTAVE  Method  (cont.) 


Attribute 

Implementation  in  the  OCTAVE  Method 

RA.5  Catalog  of  Vulner¬ 
abilities 

The  OCTAVE  Method  requires  the  organization’s  computing 
infrastructure  to  be  evaluated  against  a  defined  catalog  of 
vulnerabilities.  The  method  requires  the  use  of  vulnerability 
evaluation  tools  that  check  for  known  technology  vulner¬ 
abilities. 

RA.6  Defined  Evaluation 
Activities 

The  activities  for  the  OCTAVE  Method  are  documented  in 
the  OCTAVE  Method  Implementation  Guide,  V2.0.  The  fol¬ 
lowing  are  included  in  the  guide: 

•  guidance  for  setting  the  scope  of  the  evaluation  and  for 
selecting  participants 

•  guidance  for  conducting  each  process 

•  worksheets  and  templates  for  recording  information 
gathered  during  each  process 

•  catalogs  of  information  required  by  the  process 

RA.7  Documented  Evalua¬ 
tion  Results 

The  OCTAVE  Method  requires  the  analysis  team  to  docu¬ 
ment  the  results  of  the  evaluation. 

RA.8  Evaluation  Scope 

Guidance  for  setting  the  scope  of  the  evaluation  is  provided 
in  the  Preparation  Guidelines  of  the  OCTAVE  Method  Im¬ 
plementation  Guide,  V2.0. 

RA.9  Next  Steps 

The  last  activity  in  the  OCTAVE  Method  requires  senior 
managers  to  define  actions  to  implement  their  organization’s 
protection  strategy  and  risk  mitigation  plans.  The  activity 
also  requires  the  managers  to  assign  responsibility  for  com¬ 
pleting  the  actions. 

RA.IO  Focus  on  Risk 

The  OCTAVE  Method  is  an  information  security  risk  evalua¬ 
tion.  It  addresses  the  three  components  of  risk:  assets,  threats, 
and  vulnerabilities. 
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Table  5: 


Mapping  of  Attributes  to  the  OCTAVE  Method  (cont.) 


Attribute 

Implementation  in  the  OCTAVE  Method 

RA.  1 1  Focused  Activities 

Each  process  of  the  OCTAVE  Method  is  focused  on  identi¬ 
fying  and  analyzing  the  most  important  information  security 
issues  to  the  organization.  For  example: 

•  In  Processes  1-3,  the  facilitators  focus  the  activities  using 
assets  believed  to  be  most  important  by  the  participants. 

•  In  Process  4,  the  analysis  team  focuses  its  analysis  activi¬ 
ties  using  the  critical  assets  that  it  selects. 

•  In  Phase  2,  the  analysis  team  sets  the  scope  of  the  infra¬ 
structure  vulnerability  evaluation  using  the  organiza¬ 
tion’s  critical  assets  and  the  threats  to  those  assets. 

•  In  Phase  3,  the  analysis  team  establishes  risk  priorities 
based  on  the  organizational  impact  of  risks. 

RA.12  Organizational  and 
Technological  Issues 

The  OCTAVE  Method  is  focused  on  both  organizational  and 
technological  issues.  Phase  1  is  an  organizational  evaluation 
where  people  from  across  the  organization  identify  organiza¬ 
tional  information.  Phase  2  is  an  evaluation  of  the  informa¬ 
tion  technology  infrastructure,  resulting  in  the  identification 
of  technological  issues.  The  organizational  and  technological 
data  are  then  analyzed  during  Phase  3. 

RA.13  Business  and  Infor¬ 
mation  Technology 
Participation 

An  interdisciplinary  analysis  team  that  includes  representa¬ 
tives  from  operational  areas  and  the  information  technology 
department  lead  the  evaluation.  Personnel  from  both  the 
business  units  and  the  information  technology  department 
(including  representation  from  multiple  organizational  lev¬ 
els)  of  the  organization  participate  in  Processes  1-3. 

RA.14  Senior  Management 
Participation 

In  the  OCTAVE  Method,  senior  managers  are  required  to 
participate  in  Process  1,  where  the  managers  contribute  their 
perspectives  about  what  assets  are  important  to  them  and 
how  well  those  assets  are  being  protected.  The  senior  manag¬ 
ers  also  participate  in  Process  8,  where  they  review,  refine, 
and  approve  the  protection  strategy  and  mitigation  plans.  In 
that  workshop,  they  also  define  the  next  steps  for  implement¬ 
ing  the  strategy  and  plans. 

RA.15  Collaborative 
Approach 

The  OCTAVE  Method  consists  of  a  progressive  series  of 
workshops.  Each  workshop  requires  interaction  among  the 
people  who  participate  in  that  workshop. 

In  the  next  section,  we  focus  on  how  the  outputs  map  to  the  OCTAVE  Method. 
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B.3  Outputs  and  the  OCTAVE  Method 

Outputs  are  the  required  results  of  the  evaluation.  They  define  the  results  that  an  analysis 
team  must  achieve  during  the  evaluation.  Table  6  shows  where  in  the  OCTAVE  Method  each 
output  is  generated. 


Table  6:  Mapping  of  Outputs  to  the  OCTAVE  Method 


Mapping  of  Outputs  to  the  OCTAVE  Method 

Output 

Implementation  in  the  OCTAVE  Method 

ROl.l  Critical  Assets 

During  Processes  1-3,  staff  members  from  across  the  organiza¬ 
tion  contribute  their  perspectives  about  which  assets  are  impor¬ 
tant  for  completing  their  jobs.  In  Process  4,  the  analysis  team 
selects  the  assets  that  are  most  critical  to  the  organization. 

R01.2  Security  Require¬ 
ments  for  Critical 
Assets 

During  Processes  1-3,  staff  members  from  across  the  organiza¬ 
tion  define  security  requirements  for  their  important  assets.  The 
analysis  team  uses  this  information  during  Process  4  to  describe 
the  security  requirements  for  the  organization’s  critical  assets. 

RO 1 . 3  Threats  to  Critical 
Assets 

During  Processes  1-3,  staff  members  from  across  the  organiza¬ 
tion  identify  scenarios  that  threaten  their  most  important  assets. 
The  analysis  team  uses  the  areas  of  concern  as  input  when  it 
creates  a  threat  profile  for  each  critical  asset  during  Process  4. 

R01.4  Current  Security 
Practices 

During  Processes  1-3,  staff  members  from  across  the  organiza¬ 
tion  contribute  their  perspectives  about  which  security  practices 
are  currently  being  used  by  the  organization.  The  participants 
fill  out  surveys  and  talk  about  key  issues  during  a  follow-on  dis¬ 
cussion.  During  Process  8,  the  analysis  team  consolidates  secu¬ 
rity  practices  identified  during  the  first  three  processes. 

R01.5  Current  Organiza¬ 
tional  Vulnerabilities 

During  Processes  1-3,  staff  members  from  across  the  organiza¬ 
tion  contribute  their  perspectives  about  missing  or  inadequate 
practices  in  the  organization  (organizational  vulnerabilities). 

These  are  identified  in  conjunction  with  security  practices  using 
surveys  and  follow-on  discussions.  During  Process  8,  the  analy¬ 
sis  team  consolidates  organizational  vulnerabilities  identified 
during  the  first  three  processes. 

R02. 1  Key  Components 

During  Process  5,  the  analysis  team  identifies  key  components 
of  the  computing  infrastructure.  The  team  members  use  the 
critical  assets  and  the  threats  to  the  critical  assets  to  focus  their 
selection  of  components  to  evaluate  for  technology  vulnerabili¬ 
ties. 
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Table  6: 


Mapping  of  Outputs  to  the  OCTAVE  Method  (cont.) 


Output 

Implementation  in  the  OCTAVE  Method 

R02.2  Technology  Vulner¬ 
abilities 

During  Process  6,  the  analysis  team  evaluates  each  key  compo¬ 
nent  from  Process  5  using  vulnerability  evaluation  tools.  The 
team  interprets  data  generated  by  the  tools,  identifying  the  tech¬ 
nological  weaknesses  (technology  vulnerabilities)  present  in 
each  component. 

R03. 1  Risks  to  Critical 

Assets 

During  Process  7,  the  analysis  team  identifies  potential  impacts 
on  the  organization  for  the  threats  to  critical  assets,  resulting  in 
explicit  statements  of  risk. 

R03.2  Risk  Measures 

During  Process  7,  the  analysis  team  evaluates  the  impacts  of 
risks  based  on  a  set  of  qualitative  measures  (high,  medium, 
low).  Probability  is  viewed  as  optional  in  the  OCTAVE  Method. 

R03.3  Protection  Strategy 

During  Process  8,  the  analysis  team  creates  a  protection  strategy 
for  organizational  security  improvement.  The  team  bases  the 
strategy  on  the  organizational  and  technological  information  that 
it  identified  throughout  the  OCTAVE  Method. 

R03.4  Risk  Mitigation  Plans 

During  Process  8,  the  analysis  team  creates  risk  mitigation  plans 
to  reduce  the  risks  to  the  organization’s  most  critical  assets.  The 
team  selects  mitigation  actions  based  on  the  organizational  and 
technological  information  that  it  identified  throughout  the 
evaluation  process. 
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Glossary 


Access 


Access  path 


Action  list 


Activity 


Actor 


Analysis  team 


Area  of  concern 


a  property  of  threat  that  defines  how  a  threat  actor 
accesses  an  asset  (network  access,  physical  access). 
This  applies  only  to  human  actors. 

ways  in  which  information  or  services  can  be  ac¬ 
cessed  via  an  organization’s  network 

actions  that  people  in  an  organization  can  take  in  the 
near  term  without  the  need  for  specialized  training, 
policy  changes,  etc.  It  is  essentially  a  list  of  near- 
term  action  items. 

the  actual  operations  that  are  performed  during  the 
evaluation 

a  property  of  threat  that  defines  who  or  what  may 
violate  the  security  requirements  (confidentiality,  in¬ 
tegrity,  availability)  of  an  asset 

an  interdisciplinary  team  comprising  representatives 
of  both  the  mission-related  and  information  technol¬ 
ogy  areas  of  the  organization.  The  analysis  team 
conducts  the  evaluation  and  analyzes  the  informa¬ 
tion.  The  analysis  team  consists  of  about  three  to 
five  people,  depending  on  the  size  of  the  overall  or¬ 
ganization  and  the  scope  of  the  evaluation. 


a  situation  or  scenario  where  someone  is  concerned 
about  a  threat  to  important  assets.  Typically,  areas  of 
concern  have  a  source  and  an  outcome  -  a  causal  ac¬ 
tion  that  has  an  effect  on  the  organization. 
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Asset  something  of  value  to  the  organization.  Information 

technology  assets  are  the  combination  of  logical  and 
physical  assets  and  are  grouped  into  specific  classes 
(information,  systems,  software,  hardware,  people). 

Attributes  the  distinctive  qualities  of  the  evaluation.  Attributes 

are  the  requirements  that  define  the  basic  elements 
of  the  OCTAVE  approach  and  define  what  is  neces¬ 
sary  to  make  the  evaluation  a  success  from  both  the 
process  and  organizational  perspectives.  The  attrib¬ 
utes  define  the  process  and  organizational  require¬ 
ments  for  the  evaluation,  creating  the  environment 
in  which  the  activities  are  performed. 

Availability  when  or  how  often  an  asset  must  be  present  or  ready 

for  use 

Catalog  of  practices  a  collection  of  good  strategic  and  operational  secu¬ 

rity  practices  that  an  organization  can  use  to  manage 
its  security 

Catalog  of  vulnerabilities  a  collection  of  vulnerabilities  based  on  platform  and 

application.  It  is  used  to  evaluate  an  organization’s 
computing  infrastructure  for  technology  vulnerabili¬ 
ties. 

Checklist  a  vulnerability  evaluation  tool  that  provides  the 

same  functionality  as  automated  tools.  However,  be¬ 
cause  checklists  are  manual,  not  automated,  they  re¬ 
quire  a  consistent  review  of  the  items  being  checked 
and  must  be  routinely  updated. 

Computer  prioritization  listings  a  listing  of  the  computer  inventory  owned  by  an  or¬ 
ganization.  This  listing  typically  depicts  a  prioritized 
ordering  of  systems  or  networking  components 
based  on  their  importance  to  the  organization  (e.g., 
mission  critical  systems,  high/medium/low  priority 
systems,  administrative  systems,  support  systems). 
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Confidentiality 


the  need  to  keep  proprietary,  sensitive,  or  personal 
information  private  and  inaccessible  to  anyone  who 
is  not  authorized  to  see  it 


Configuration  vulnerability 


Critical  assets 


Desktop  workstation 


Design  vulnerability 


Destruction 


Disclosure 


Evaluation  criteria 


Hardware  asset 


Home  computer 


a  weakness  resulting  from  an  error  in  the  configura¬ 
tion  and  administration  of  a  system  or  component 

the  most  important  assets  to  an  organization.  The 
organization  will  suffer  a  large  adverse  impact  if 
something  happens  to  critical  assets. 

hosts  on  an  organization’s  networks  that  staff  mem¬ 
bers  use  to  conduct  business 


a  weakness  inherent  in  the  design  or  specification  of 
hardware  or  software  whereby  even  a  perfect  im¬ 
plementation  will  result  in  a  vulnerability 

the  removal  of  an  asset  from  existence;  the  asset 
cannot  be  recovered 

the  viewing  of  confidential  or  proprietary  informa¬ 
tion  by  someone  who  should  not  see  the  information 

a  set  of  qualitative  measures  against  which  a  risk  is 
evaluated.  Evaluation  criteria  define  high,  medium, 
and  low  impacts  for  an  organization. 

information  technology  physical  devices  (worksta¬ 
tions,  servers,  etc.) 

home  personal  computers  that  staff  members  use  to 
access  information  remotely  via  an  organization’s 
networks 
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Hybrid  scanner  a  vulnerability  evaluation  tool  that  targets  a  range  of 

services,  applications,  and  operating  system  func¬ 
tions.  Hybrid  scanners  may  address  Web  servers 
(CGI,  JAVA),  database  applications,  registry  infor¬ 
mation  (e.g.,  Windows  NT/2000),  and  weak  pass¬ 
word  storage  and  authentication  services.  These  are 
also  known  as  specialty  and  targeted  scanners. 

Implementation  vulnerability  a  weakness  resulting  from  an  error  made  in  the 

software  or  hardware  implementation  of  a  satisfac¬ 
tory  design 

Impact  the  effect  of  a  threat  on  an  organization’s  mission 

and  business  objectives 

Impact  value  a  qualitative  measure  of  a  risk’s  impact  to  the  or¬ 

ganization  (high,  medium,  or  low) 

Information  asset  documented  (paper  or  electronic)  data  or  intellectual 

property  that  is  used  to  meet  the  mission  of  the  or¬ 
ganization 

Integrity  the  authenticity,  accuracy,  and  completeness  of  an 

asset 

Interruption  the  limiting  of  an  asset’s  availability;  interruption 

refers  mainly  to  services. 

Key  classes  of  components  types  of  devices  that  are  important  in  processing, 

storing,  or  transmitting  critical  information.  They 
represent  related  assets  to  critical  assets. 

portable  personal  computers  that  staff  members  use 
to  access  information  remotely  via  an  organization’s 
networks 

the  limiting  of  an  asset’s  availability;  the  asset  still 
exists  but  is  temporarily  unavailable. 


Laptop 


Loss 
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Modification 


an  unauthorized  changing  of  an  asset 


Motive  a  property  of  threat  that  defines  whether  an  actor’s 

intentions  are  deliberate  or  accidental.  This  applies 
only  to  human  actors.  Motive  is  also  sometimes  re¬ 
ferred  to  as  the  objective  of  a  threat  actor. 


Networking  component  devices  important  to  an  organization’s  networks. 

Routers,  switches,  and  modems  are  all  examples  of 
this  class  of  component. 


Network  infrastructure  scanner  a  vulnerability  evaluation  tool  that  focuses  on  the 

components  of  the  network  infrastructure,  such  as 
routers  and  intelligent  switches,  DNS  (domain  name 
system)  servers,  firewall  systems,  and  intrusion  de¬ 
tection  systems 


Network  mapping  tools 


Network  topology  diagrams 


Operating  system  scanner 


Operational  practices 


software  used  to  search  a  network,  identifying  the 
physical  connectivity  of  systems  and  networking 
components.  The  software  also  displays  detailed  in¬ 
formation  about  the  interconnectivity  of  networks 
and  devices  (routers,  switches,  bridges,  hosts). 

electronic  or  paper  documents  used  to  display  the 
logical  or  physical  mapping  of  a  network.  These 
documents  identify  the  connectivity  of  systems  and 
networking  components.  They  usually  contain  less 
detail  than  network  mapping  tools  provide. 


a  vulnerability  evaluation  tool  that  targets  specific 
operating  systems  (OS)  such  as  Windows  NT/2000, 
Sun  Solaris,  Red  Hat  Linux,  or  Apple  Mac  OS 

security  practices  that  focus  on  technology-related 
issues.  They  include  issues  related  to  how  people 
use,  interact  with,  and  protect  technology. 


Organizational  vulnerability  a  weakness  in  organizational  policy  or  practice  that 

can  result  in  unauthorized  actions  occurring.  They 
are  indications  of  missing  or  inadequate  security 
practices. 
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Outcome 


People  asset 


Principles 


Protection  strategy 


Protection  strategy  practice 


Risk 


Risk  management 


Risk  mitigation  plan 


Risk  profile 


a  property  of  threat  that  defines  the  immediate  out¬ 
come  (disclosure,  modification,  destruction,  loss,  in¬ 
terruption)  of  violating  the  security  requirements  of 
an  asset 

the  people  in  the  organization,  including  their  skills, 
training,  knowledge,  and  experience 


the  fundamental  concepts  driving  the  nature  of  the 
evaluation.  Principles  define  the  philosophy  that 
shapes  the  evaluation  process. 

the  strategy  that  an  organization  uses  to  enable,  ini¬ 
tiate,  implement,  and  maintain  its  internal  security.  It 
tends  to  incorporate  long-term  organization-wide 
initiatives. 

action  that  helps  initiate,  implement,  and  maintain 
security  within  an  organization.  A  protection  strat¬ 
egy  practice  is  also  called  a  security  practice. 


the  possibility  of  suffering  harm  or  loss.  It  is  the  po¬ 
tential  for  realizing  unwanted  negative  consequences 
of  an  event.  Risk  refers  to  a  situation  where  a  person 
could  do  something  undesirable  or  a  natural  occur¬ 
rence  could  cause  an  undesirable  outcome,  resulting 
in  a  negative  impact  or  consequence. 

the  ongoing  process  of  identifying  risks  and  imple¬ 
menting  plans  to  address  them 

a  plan  that  is  intended  to  reduce  the  risks  to  a  critical 
asset.  Risk  mitigation  plans  tend  to  incorporate  ac¬ 
tions,  or  countermeasures,  designed  to  counter  the 
threats  to  the  assets. 

the  range  of  risks  that  can  affect  an  asset.  Risk  pro¬ 
files  contain  categories  that  are  grouped  according  to 
threat  source  (human  actors  using  network  access, 
human  actors  using  physical  access,  system  prob¬ 
lems,  other  problems). 


124 


CMU/SEI-2001-TR-016 


Script 


Security  component 


Security  practices 


Security  requirements 


Server 


Software  asset 


Storage  device 


Strategic  practices 


System 


a  vulnerability  evaluation  tool  that  provides  the 
same  functionality  as  automated  tools.  Scripts  usu¬ 
ally  have  a  singular  function.  If  a  large  number  of 
items  are  being  evaluated,  a  corresponding  number 
of  scripts  will  be  required.  Scripts  require  a  consis¬ 
tent  review  of  the  items  being  checked  and  must  be 
routinely  updated. 


device  that  has  security  as  its  primary  function.  A 
firewall  is  an  example  of  a  security  component. 

actions  that  help  initiate,  implement,  and  maintain 
security  within  an  organization.  A  security  practice 
is  also  called  a  protection  strategy  practice. 

requirements  outlining  the  qualities  of  information 
assets  that  are  important  to  an  organization.  Typical 
security  requirements  are  confidentiality,  integrity, 
and  availability. 

hosts  within  the  information  technology  infrastruc¬ 
ture  that  provide  information  technology  services  to 
an  organization 

software  applications  and  services  (operating  sys¬ 
tems,  database  applications,  networking  software, 
office  applications,  custom  applications,  etc.) 


devices  where  information  is  stored,  often  for 
backup  purposes 

security  practices  that  focus  on  organizational  issues 
at  the  policy  level.  They  include  business-related  is¬ 
sues  as  well  as  issues  that  require  organization-wide 
plans  and  participation. 

a  logical  grouping  of  components  designed  to  per¬ 
form  a  defined  function(s)  or  meet  a  defined  objec- 
tive(s) 
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System  of  interest 


the  system  that  is  most  closely  linked  to  the  critical 
asset 

Systems  asset  information  systems  that  process  and  store  informa¬ 

tion 

Technology  vulnerability  a  weakness  in  systems  that  can  directly  lead  to  unau¬ 

thorized  action.  Technology  vulnerabilities  are  pre¬ 
sent  in  and  apply  to  network  services,  architecture, 
operating  systems,  and  applications.  Types  of  tech¬ 
nology  vulnerabilities  include  design,  implementa¬ 
tion,  and  configuration  vulnerabilities. 


Threat  an  indication  of  a  potential  undesirable  event.  A 

threat  refers  to  a  situation  in  which  a  person  could 
do  something  undesirable  (an  attacker  initiating  a 
denial-of-service  attack  against  an  organization’s 
email  server)  or  a  natural  occurrence  could  cause  an 
undesirable  outcome  (a  fire  damaging  an  organiza¬ 
tion’s  information  technology  hardware).  Threats 
have  defined  properties  (asset,  actor,  motive,  access, 
outcome). 

Threat  profile  the  range  of  threats  that  can  affect  an  asset.  Threat 

profiles  contain  categories  that  are  grouped  accord¬ 
ing  to  threat  source  (human  actors  using  network  ac¬ 
cess,  human  actors  using  physical  access,  system 
problems,  other  problems). 

Vulnerability  a  weakness  in  an  information  system,  system  secu¬ 

rity  practices  and  procedures,  administrative  con¬ 
trols,  internal  controls,  implementation,  or  physical 
layout  that  could  be  exploited  by  a  threat  to  gain  un¬ 
authorized  access  to  information  or  disrupt  process¬ 
ing.  There  are  two  basic  types  of  vulnerabilities  (or¬ 
ganizational  and  technology). 

Vulnerability  evaluation  approach  an  approach  for  evaluating  each  infrastructure  com¬ 
ponent,  including  who  will  perform  the  evaluation 
and  the  selected  tool(s) 
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Vulnerability  summary 


Wireless  components 


a  summary  of  the  technology  vulnerabilities  for  each 
component  that  is  evaluated.  A  vulnerability  sum¬ 
mary  includes  the  types  of  technology  vulnerabili¬ 
ties  found,  when  they  need  to  be  addressed,  their  po¬ 
tential  effect  on  the  critical  assets,  and  how  they  can 
be  addressed. 

devices,  such  as  cell  phones  and  wireless  access 
points,  that  staff  members  may  use  to  access  infor¬ 
mation  (for  example,  email) 
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